Recently Marcelo told me, that’s weird, how we do 10% research and specification, 40% implementation and 50% debugging in this industry. I’m more used to 70% research and specification, 20% implementation and 10% debugging. He was working in the hardhware industry for a while, and just came to a service-based company. This is actually a very interesting remark and it reminded me when I was in my twenties when I was working as a construction worker.

When I was young there was no internet and I had a 10 years break from computers. I had to take stupid jobs like working on construction sites for low wages. After that I went to art school and later on I worked on building sets for business shows. I have been shocked by the gap between those 2 worlds. When building a house, there is so much time spent writing plans, thinking things in advance. While in the show-business construction pattern, it was mostly about improvisation and managing inflexible time constraints, with one-time-use construction.

I feel there is the same gap in the software industry. Well it’s not exactly the same for sure, but the paradigm feels alike. In service software production, SaaS or ISP businesses, we tend to under-engineer the production. There are perfectly legitimate reasons for that, the life-cycle of a platform of service is quick, volatile and the value is not in the software asset but in the customer-user experience.

The Agile organization model reinforces this pattern, by providing a substitute to the early specifications, in the form of user experiences description. All this is fine and good. For a time. But with years passing we can see so many occurrences of ‘temporary’ projects becoming indestructible legacy monsters. It’s like there was some kind of tipping point where the development should shift from under-engineered to well-engineered but it’s rarely anticipated properly enough.

But it’s pretty hard to address that kind of problem. Throwing away the early instances is very costly, especially when the organization is shaped by a fast-paced reactive production model. Introducing proper engineering at early stages is also not a clever option, as the product has to adapt to the service, which depends on a constant feedback loop with the users.

I have the feeling that there is something missing. Like an evolution of agile that could include seeds of later engineering. Some way to make possible to start fast, and evolve in a solid and slower model later on without crisis or disruption. This is the perspective that I think was missing in that article I cited on green ruby 145. But I don’t know the answer to that problem. I suspect it will emerge by itself in the few next years.