A series of personal thoughts about software architecture.
I’m currently working in a big company. What I mean by big? : big dreams, big teams, big challenges and of course, a big budget to make it happen. So, I’ll try to keep it up as abstract as I can, to make it interesting for everyone to follow, but I’m pretty certain this is only an issue at scale, but we’ll get to that later.
How a startup creates software?
Starts with coding: Some people gather to code in some repo and they set up some basic rules to make it happen: what branch is for development and what other one is for releases, some board where product progress will be reflected, they choose language and some tools and they jump into coding.
And all of the sudden the magic starts to happen: the team has great communication because they are all building together, learning from the other’s technique. If it is camel or pascal case it’s actually taken from the industry in the language selection. There’s no discussion yet on what’s the best option to deploy it. No particular standard is needed because they seem to not add any value at this point so why bother investing time into it?. So life is basically: take requirements, design, code, test, rinse and repeat.
They reach production over a non-optimal and insecure cloud configuration, but after some mistakes, and after further iterations, the software seems stable.
How a big company creates software?
If we want to get some code, first we need some hands, so the process starts with Resources Allocation. We need to allocate people (devs, testers, product owners, architects and so on) for a particular amount of time and understand what they need to do their work: Boards, Repository, Cloud project and so on.
So, the first question that some unlucky product owner will have to sort out is: “How long is this going to take?”. Project length is a decisive factor to do or discard a project in a big company: If the perception is that it takes too long the sense of urgency will be low, if it takes too little the sense of scope will be minuscule, and therefore there’s no winning situation. As the project has to make sense for tech and non-tech here it comes in handy: The Roadmap! (we’ll talk about it next time).
Finally, the first requirement arrived, and it was an easy one. Once the coding is ready with over 95% of testing code coverage (because it will be required), all members are asked to create a pull request for someone else to review it. If it’s correct after human validation, the merge will occur and the next environment (staging, test, and so on) will be tried to be tested…
To reach production, the product will have to follow tight standards such as: use corporate pipeline, put traceability headers, in some cases be Richardson Maturity Model level 2 compliant, use logging standard, run veracode or sonar in the pipeline, hardening, dependency checks, corporate proxy, and so on and so forth.
What happens in a big company that in a startup doesn’t, to build software in such a complicated and frictioned way?
Legacy or monolithic systems. In big companies surely exist legacy software at core or close. And deal with legacy software changes you in conservative ways that can affect the mindset of the people that is working in the future state.
How? well, if you have to tackle with legacy software your desire (your ideal world) will be having software that ages well: loosely coupled, standarized, compliant, and in many ways, idealistic. However, industry shows permanently that decisions about tech tools must be revisited in a regular basis. New languages, frameworks, data products, and pretty much all technologies are being built and improved everyday.
Our ancestors, that lived among monoliths, showed us the path to bring the monolith down and break it apart into several microservices. Why? so when you need to change, improve or deprecate some component, you could do it in isolation, without affecting the overall behavior. And that was actually great: instead of being a human body, that has to be well cared entirely to be alive, this was more like a car, that if some piece is making a mess, you could replace it individually without having to take care of the entire car.
Unfortunately, mindsets and rules don’t change as fast as technologies can, so we are now expecting microservices to age well. This will mean that instead of pushing the rules and guidelines over one monolith, we are pushing them over 25 microservices with the same strength, making the process, of course, more extensive and expensive.
In my opinion, in some part of the process we missed the important part: You shouldn’t be regulating components to age well, you should be regulating to have easily disposable/replaceable components. If you are aware of the disposable nature of software you’ll just ask for the necessary and get rid of complicated and long term rules. On the other hand, if you think software it’s a long-term commitment it probably makes sense to have intense and tight rules.
That mindset change, very subtle, is the key to have guidelines that represent the current state of the art and make developers to embrace rules instead of perceive them as unnecessary bureaucracy.
What do you think? regulate to age well or regulate to easily dispose?.
