Wednesday, September 30

DuctTape Guy or Craftman?

I just finish reading The DuctTape Programmer from Joel Spolsky and Uncle Bob's response this morning, and I have to say what a contrast in their views of how to define a good programmer. I completely agree with Joel as a programmer for business in a real world especially if you are running or working for a startup company where you believe there are only a few months window to achieve what you set out to achieve before somebody else eats your lunch, over engineering or pre-mature optimization over business functionality is definitely stupid and sometime even lethal. If you can achieve the same functionalities with a simpler design or a simpler tool or both then stick with the simpler version. Remember

"Simplicity is the ultimate sophistication." -- Leonardo da Vinci

Once you have been trying to make everything you bulid as simple as possible but not any simpler, you will probably realize its actually not a "simple" goal to achieve sometimes even turning out way more difficult than using the complicated alternative. However like Uncle Bob I strongly disagree with Joel's constant bash on Unit Testing, since unit testing is not really a technology or even a technique of choice but next step in the evolution of programming. Its not like a decision about multi-threading vs. single-threading or even using a certain design pattern or not, either way you can implement the functionality so there is no arguement here ship the single thread implementation. When it comes down to unit testing there is no alternative, different technology or framework for implementing your test cases but not the principle itself. On top of that when you use unit test in a TDD way it actually has not much to do with testing, but instead a brand new way (compare to the triditional non-TDD way at least) to materialize your design, drive your implemetation, and a core enabler for many other useful Agile practices such as Refactoring.

I believe when you are building a product, just like building a company, carrying some debt (in this case the technical debt) is healthy and beneficiary to the growth, but the balance is essential here don't declare technical bankrupcy before you can even ship something. By the way, even if you are working in a startup, don't put too much emphasize to the First-Mover Adavantage since its just a marketing myth. The recent success in Google and Apple's iPod are the perfect examples of why the first-mover advantage is highly overrated. For startup I truly believe the vision, innovation and quality are the key building blocks for any enduring success.

Tuesday, September 22

Technical mess is a one way ticket to Technical Bankrupcy

I just finished reading Uncle Bob's new post A Mess is not a Technical Debt. Lack of understanding of this key differentiation is so common in the industry. I have witnessed many projects and businesses creating a mess thinking that is a way to produce something under tight budget and timeline. They did not realize this debt (if you consider debt way beyond your affordability is still a debt) is so overwhelming, it basically turns out to be a one way express ticket to technical bankrupcy. It's an especially popular view among startups. Many startup entrepreneurs are very cautious when it comes taking on finicial debt however reckless when it comes to technical debt. When the debt accumulates to a certain turning point then it is no longer debt but a suicide. I consider a suboptimal algorithm is a technical debt or even unit test coverage from 90% to 80% is a debt however unwise, but 0% unit test coverage is not a debt but a bandrupcy, a train wreck in slow motion resulted many slow and painful deaths I witnessed in my almost a decade long career.

One thing still perplex me is I have also witnessed a few companies enjoyed some pretty decent finicial success while creating a big technical mess...