Home Repair - The Initial Frontier

Good gracious!!  It has already been 5 years since my last post?!  I guess it is true that time flies a lot faster as you get older.  Anyways, with works and life and pandemic, this site really got neglected, but I am not here today to talk about this.  Today, it is about all the home repair projects in the last couple years and what I have learned so far.

One of the first task I took on was re-painting fully rusted round metal handrail back in 2019.  This is the type that common seen by a front door.  You can see similar picture on the right side here.  The project took four weekends to complete.  It started with sanding down existing rusted paint.  And don't let anyone (or any article) fools you into hand sanding paint off metal handrail.  I made the mistake of doing so using sandpapers and wire brushes. 

It took a day to get few feet of paint and rust off.  Needless to say, I could not imagine finishing the job in few weeks.  Fortunately, my brother with more home repair experience loan me a hand sanding machine, which turned out a life saver.  The constant vibration for hours from holding the sander was hard on the arms, but at least it got the job done much faster.

Anyways, after the scrub and clean, I went ahead and paint with Rust-Oleum Protective Enamel Brush-On Paint.  And I have to say, this paint is really excellent.  The paint stay together to form a nice and smooth texture, but does not clump.  Given this is my first true paint job, I am very satisfy with out it turned out even to this day. 

Lesson here?  Persistent and hard work does not pay off without the right tools/situations.  Sure I could have spent couple months sanding the whole rail off using sandpaper and wire brush.  But if your time is valuable, buy or borrow a machine to do efficiently if you can.  After all, there are still lots of chores to do around the house every weekend. 😅

Work: Psychological Safety -- an ingredient, not a recipe

This was a while back, early in the year, when someone on my team email an article published by Google about what make a good team.  The one buzzword that got thrown around was psychological safety.  Basically,the ability to express thoughts without being shamed and fail without being blamed.  If you have not read about it yet, try reading it at NYTimes or reWork

• http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html
• https://rework.withgoogle.com/blog/how-to-foster-psychological-safety/

I do think psychological safety is an essential part of a good team.  Innovation requires a lot of experiments and failures.  Getting blamed for each and every failures is very detrimental.  It would be like living with a family member who points out all your imperfection on a daily basis -- that dish is not clean, you are driving too slow, the housework is not done yet, the bill is still unpaid, there is dust on the table, the grass is (few inches) too tall now, the food is too salty/sweet/tough/bland/cold/unhealthy, etc.  Yeah... nothing said love than being reminded about every troubles and flaws.

At the same time, I have a feeling that psychological safety will ended up being the grand philosophy to create a perfect project instead of an ingredient of a good project.  Eventually, it will be re-interpret, exploited, and deemed as a wrong idea.  I like to compare this to a sugar in any cake.  Yes, all cakes need sugar, but it is not the only ingredient and too much can be bad...

After reading the articles, I have been thinking for a while about my own situation in life, and came to the conclusion that the three ingredients that make a good team are...

1. Knowledge -- the logical thinking and technical ability to get things done.
2. Passion -- the drive to bring people together and motivation to get things done.
3. Compassion -- the openness to changes and acceptance of failures.

From my own 11 years in software development, I have worked on 12 teams (the privilege of being in a Tiger Team), two of my top three managers have nothing to do with Computer Science major.

In shortness of time, I have to stop this post now...  Who know when will I ever blog again...

Work: Dependencies Analyzer

Recently, there is a post by Google on Venture Beat regarding causes for build failures.  If there is one thing about Google I give credit for is the hunger and drive beyond the current standard.  They want perfection, or at least as much as possible.  Anyways, the article break down the causes and one of which for Java and C++ is libray dependency.  So, that should not shock anyone working with Java and C++ long enough.  You forgot to include a file and kaboom! A compiler failure five minute later and back to typing one line, and recompile everything again... (@__@)

However, one idea just popped up in my head few minutes ago.  Another big reason for a major breakage is library upgrade.  If you ever work on any software project, you will realized that libraries get updated consistently due to additional features, fixed bugs, or security issues (like HeartBleed).  So, how can you make sure that dependencies upgrade will not break anything?  Smoke tests and unit tests, of course!

If those builds have tests in-place, then it should detect the unexpcted anomalies.  However, current build systems (ex: Jenkins) do not know anything about dependencies.  This is a drawback and a big deterrent to updating to a new library.  It goes against "Do not fix something that did not break" philosophy.  The reason is not because upgrading is bad, but upgrading takes work!  A lot of tedious and no appreciation work. 

My proposal would be to have a build system that can recognize each project's dependencies.  It could be a link to some folder and a script to parse the version number.  It could be manually entered URL, like GitHub.  It could anything really.  If the build system can understand each build's dependencies, then it can be expanded further to do mini-jobs like... find new builds, auto test each new dependency with the current source code, back-port a dependency library to an older version (useful for security fixes, and detect which older versions can be updated to the latest library), report version numbers of each dependency library, test if a specific version is compatible with the latest libraries.  Once these jobs are created, library update/upgrade would be a simple problem.

Obviously, this is an ideal situation.  Most project in most company still does not have a unit test, let alone a smoke test or a validation test.  Again it takes effort and support from management to really do this.  But once it is done, the team can achieve a speedy development with fewer maintenance!!

Work: What Went Wrong?

If everyone thinks the same way, then society would fail at the first stupid idea

Over the last few days, I got some time to think about what make and break a project. After some long thought, it comes down these few reasons:

• people: managers, co-workers, supporting teams, external teams
• plan: vision, milestones, requirements, designs
• execution: tools, communications, automation
• non-engineering: timeline, finance, competitors

So, why oh why... do projects fail? Because there are thousands of ways it could go wrong. And should one factor stands out too much, it becomes a loose string in a sweater that slowly taking other parts down with it.
      If the leader has no vision, then there is no direction
      If the team does not have the right tools, then the product will be delayed
      If the co-workers do not get along, then parts won't fit well together

So, when I was asked what went well, I could have given the usual answer -- we work hard, we tried to plan, we created some automation, etc. But I answered with what went wrong -- lack planning, and insufficient tools. However, I never got around to people... It is sad to see that there are much more to be said, but change-agents limit the scope. If the goal is to bring changes, then all ideas should come before any time constraints. The insufficiency of patient, sincerity, and humility is what I see, and it means nothing will change. THAT is what went wrong after all the wrongs...