Mr Martin Fowler was one of the founding members of the Agile Manifesto, author of many books including my favourite Refactoring (1st edition was written in Java, and the latest edition in Javascript), and a great speaker at many conferences. I learned a lot from watching his talks at the previous GOTO conferences. Hence, when I found out that he is coming to Singapore to speak at the first Singapore’s XConf, I immediately signed up for the tickets.
Mr Fowler liked to use the overarching title “Software Development in the 21st Century” for his various talks, but the contents of each of those talks would vary. This time, it consisted of 2 topics: a) Economics of Software Quality and b) Practices for an Agile Codebase.
Economics of Software Quality
Mr Fowler started off in a rather humorous manner, mimicking his counterpart Mr Robert C. Martin (which the fraternity called as Uncle Bob), about how absolute and loud Uncle Bob would detest when bad or buggy software was allowed to be released. It is a heinous sin to commit, and no one must do that, he would say. Mr Fowler would, however, take a more measured approach to evaluate such an issue.
He reasoned that for non technical people such as business owners, they have their set of problems to address and targets to meet. When they look at software as a product, they would view the customer facing features and the underlying software quality as items that are “tradable”. Taking 3 main points — Pleasant user interface, Few defects, Good modular architecture — as example, it would be common for business owners to draw the line and separate Good modular architecture from the other two.
Depending on the resources available, business owners would adjust that line and give what bandwidth was left after developing the features to touch up on the Internal Quality. While this approach does help to accelerate the product’s time-to-market, this momentum would be short-lived — as short as within a few weeks. Design Stamina Hypothesis, he explained with a parabolic chart, charts out how a software with no or poor architecture design would have quick growth in cumulative functionality at the beginning, but would slow down logarithmically as the time of the project stretches.
Software projects which took care to set up a good design architecture may have relatively lesser features at the beginning of the project. However, because it was built with proper workflows and steady foundations, it would quickly catch up and surpass the growth rate of the former project steadily.
He gave another analogy of how software development can be viewed as a bank account with existing debts. When each new feature is built on to the software, one can choose either to incur more debt on top of this principal amount, or pay off a portion of it: that choice depends on the quality of the code that implemented the feature.
Therefore, Mr Fowler plotted the attitudes people would have about such technical debts on a quadrant, segmenting between Prudent or Reckless, then Deliberate or Inadvertent. On the top right quadrant (Prudent and Deliberate), he explained that generally, well-intentioned people would have such an attitude — admitting the fact that they have incurred technical debt, but have to bite the bullet and deliver the product, and mentally aware of the problems and consequences that they need to deal with later.
There would also be people who are totally unaware of software development best practices and the technical debt they are incurring, hence reckless but inadvertent in nature, as they do not know what they not know. What would be more upsetting, would be people who are aware of their debt, but wilfully choose not to do anything about it, essentially being deliberately reckless about the matter.
One can only get away from the consequences of such wilful stubbornness, when the term of the project is short-lived — short enough before the Design Payoff Line intersects with the project’s velocity curve. This may apply to one-off campaign-related short projects, which one does not need to worry about maintenance.
Finally, Mr Fowler summarised, when we promise clients to build software with many features but without proper design and architecture, we are ultimately stealing money from our clients: the money — both physical capital and time costs — that the client would need to pay to maintain the software in the future. As software developers, he rallied, we should upkeep our professional ethics to not cause deceit and harm to our clients and users. With that conclusion, he ended the first part of his talk.