I’m in the processes of migrating my blog to a static website generator (Gatsby).
So I ran into this article I wrote in 2012. I’d like not to lose it in the migration, so I read it and I am amazed by how valid these thoughts are even today, so I am reposting it below without any changes. Please keep in mind this was 2012.
I don’t know if this sounds familiar to you, but I have been in this situation more than a few of times already. Happens a lot to small and medium businesses, but large software companies are not safe either.
Higher management wants new features implemented, if possible yesterday. Marketing needs this and that (tons of transactional stuff). If the company is small enough or you have the “great” open space plan, they will just come next to the developer asking for the feature or the data. That’s fast, flexible and agile in a way, but in the long run it will totally kill productivity.
So, to cope with the demands, you hire more programmers and more code gets written in more ways than you can count. But it seems like it’s working and it is working … until it doesn’t.
You hit a certain point when just doing something simple will affect the delicate balance of things in your product in a way impossible to predict.
Most of the people I talk to about software architecture tell me about what great solutions they came up with last night, they even have some scrum knowledge and some of them (it’s rare) can even write quality code and maybe explain you a simple algorithm like Backtracking or Dijkstra.
However, even if they talk about things like code reviews or unit testing, nobody really does that. And that is what I want to talk about.
Nobody really obeys the rules. People don’t like writing comments and they like writing documentation even less. (does anyone write self documenting code ?)
As a result, you end up in a place where it’s so difficult to even do some simple things. Your application or website becomes slower and slower and you need to find someone or something to clean it up.
What do most companies do? They “refactor”. That is ok, only that sometimes this is really time consuming and keeping functionality while rewriting the code is not always the purpose. You might want to add/remove/bundle functionality together. This would break compatibility with whatever used that interface/class/function before. So you end up having to rethink and rewrite the whole application/module/website. That is ok too, takes more time, but it gives you quality code, fast execution time, flexibility, a decent level of abstraction. Make sure rewrites are done by your most skilled programmers, or they might just be a waste of time.
They (software architects) think on the lines of “we would be better off by implementing regular code reviews, unit tests, continues integration, automated testing, as well as spending a week testing and thinking before implementing”, but they forget about it the next day, because there is a new urgent feature for that event or customer presentation.
What people don’t understand is that implementing new features fast is good, but having good architecture is what let’s you do it fast all the time, not only at the beginning when your application is small and clean.
It’s the difference between keeping your room tidy and having to clean it completely every week trying to put new order into things.
In conclusion, this is what most people are building:
And this is what the board think the product looks like:
I argue it is the duty of any architect to pass this message to the upper management.