Many decisions on software projects are driven by productivity concerns especially when a project is successful, its market grows and so does the complexity in terms of both domain knowledge and clients’ needs. Unanticipated shifts of scope are likely to occur and the product requires more and more customization. As highlighted by Lispy, many teams “implement awful hacks" to adapt rapidly to new needs and "to keep a client happy enough to keep the money coming in.” This is what he refers to as “the pain of success” given the implications for the quality of the software.
Bob Martin describes these implications and argues that quick-and-dirty approach cannot be sustainable in a long run because it would inevitably result in slowing the project down:
I was at a client recently. They are a successful startup who has gone through a huge growth spurt. Their software grew rapidly, through a significant hack-and-slash program. Now they have a mess, and it is slowing them way down. Defects are high. Unintended consequences of change are high. Productivity is low.
[…] quick-and-dirty is an oxymoron. Dirty always means slow.
Often hack-and-slash approach is justified by the assumption that business software is anyway messy but Bob Martin strongly disagrees with that. He argues that even though business rules tend to be “complicated, arbitrary, and ad-hoc”, the code, on the contrary, has to be as clean as possible:
You cannot manage the mess of the rules if they are contained by another mess! The only way to get a handle on the messy rules is to express them in the cleanest and clearest code you can.
According to Roland Kaufmann, commenting on Martin's article, what actually explains the primacy of productivity concerns is “an insane internal rate of return which makes any short-term saving preferable over long-term gain.” This is particularly true since many managers operate under the assumption that any project going long enough cannot avoid periodical design and re-implementation from scratch. This was highlighted in a comment whose author also argues that such short term and productivity-oriented rationality is one of the reasons why computer science graduates are often blamed for not being able to write software.
It is true that “computer science and software engineering are very different disciplines” as highlighted by David Chisnell. The latter “teaches the process of developing software in terms of both tools and processes” whereas computer science course would only “briefly touches on these topics” and is not meant to be a “vocational training”. Graduates are exposed to many languages but do not get any in depth knowledge about them and related tools. Hence, they are likely to be unable to code productively and respect tight deadlines. As it was emphasized by one blogger “their inadequacies are visible to all”, whereas someone “with little or no large-scale design/architecture smarts” making fast progress would not be “personally blamed when their poor large-scale design decisions cause the whole system to slowly become unmaintainable”, because “their earlier successes make management think the eventual failure was likely unavoidable.”
However, unproductive computer science graduates have, according to Lispy, skills that are crucial for successful development of projects as they grow in size and complexity. “Adding tons of features to the software, or do expensive custom work on each deal" is "way too much friction to scale” and Lispy argues that even with luck and hard work “untrained “street programmers” can only get the project to a certain point to grow beyond which, they require "tools to help them write their tools”. Bob Warfield, for instance, advocates for domain specific languages as a means to “make it possible to maneuver a bit at low cost and give customers what they want". Lispy believes that computer science expertise is necessary for providing such tools because it requires operating at a different level of understanding. Einstein used to say that “the significant problems we face cannot be solved at the same level of thinking we were at when we created them.” To solve problems faced in real world development one may need computer science graduates who apparently are unable to code under real world productivity-oriented requirements.
