How many times have you heard: "We're only going to get the architect for the first X time of the project. Then he'll be 'on-demand'"? How many times (besides total fuckups, of course) did hi actually show to meetings?
Why is that the case?
I think the main reason for this state of things is that there is somehow a notion that architecture is something that needs to be set in stone once, and then everything is built on top of it. There is somehow this connection to buildings and that once an architect has designed the building it stays throughout the build process.
I hate to break it to you, but oh man is that metaphor false to the deepest levels of hell!
Comparison to building a house
So let's say there are 4 stages to building a house:
- getting a land
- designing a house
- building it
- using it
If you think about it, then building software is pretty-much the same - only the names are different:
- securing founds
- building it
- deploying it
- profiting (hopefully!)
Now, there is a difference in the two middle stages.
Designing a house
Traditionally, in the real estate business, changing a design from a block to a wing-based system is not a thing that's done very frequently. After all, once the general shape of it is set, everything else it built "on top of it".
It's even less possible once the construction phase starts, and it turns out the entire groundwork needs to be undone, including the first and second floors of that 20 stories building. That would be madness, right?
What if I told you that while you're living in your freshly built house, someone would scale it up and down depending on how many people are currently present? Or even depending on which room they're occupying. That's a mind-fuck, isn't it?
Designing a software
Well, what if it wouldn't be that insane to think that you do have the possibility to redesign the general plan of the building, even change the number of floors dynamically and then to test, like "for real", if that meets the client's need?
Guess what! That is exactly how software is done!!!
So architects think they design something, and then it's like the basement and bricks - all set in stone. But in point of fact, it is very much not. It's subject to change just like every other part of the system, be it a single line in a back-water services or the key optimization of the company's most treasured secret AI whatever.
And if it isn't...
Architecture is just code
Countless times, I'm asked to draw pretty pictures of the architecture of a system I work on. I have no idea how is that going to help anyone understand what I need them to do if they don't even understand how a simple for loop works, but hey - the customer wants, the customer gets.
The problem with that is, that the non-tech guys trying to understand the grand design do think about it as the architecture plan of a house. It is not. It is not a house we're building here. Just please, get over it, m'key?
Now that we have that out of the way, I need to make sure we are on the same page here:
Architecture is the result of all coding activities, both heavenly-inspired and hellishly-guided. It doesn't matter who told you otherwise. No amount of pretty pictures will ever give you an accurate insight into an architecture of a system than the code itself. That is where The Architecture is. And it needs to change!
The goal of an architecture
It is my strong belief that coding is not only an art. It is a mixture of both craftsmanship and art.
As such, software development takes skills, out-of-the-box thinking, but also professionalism and modesty. I don't care if you're the CTO of some company or a junior that just joined. If you're wrong, and you can be proven wrong, then you're wrong. It will surface sooner rather than later.
That adheres most of all to architects. From my experience, those are guys that join a project in the beginning for a few days, set up some scaffolded horse manure, shout how "XYZ has taken over the world of software development and it sexy it will all be". Then they unload a whole pile of crap onto a team that has no idea what the actual fuck is going on. Weeks from then, the team has finally gotten rid of the bullshit introduced by the highly paid individual, but they're so bored with the project that even the newest toys don't motivate them to work on the project anymore. In other cases, the architect was so messed up the project, even though perfectly doable in the allotted time, will either stretch or be abandoned all together, causing investors to lose money.
It's sad, but true. Just look at the rate people change jobs in IT. It's madness!!!
Architecture is in the code
Ok, you might say that we don't have architecture in how the services are deployed or how they run on the server. First of all, that's no longer true if you use something like docker with docker-compose or k8s, and with that, you can again start thinking in a bigger picture - the architecture level.
But does that mean you can't add/remove services? Well... you can! And you can't - if you want your system to remain stable. That's a common problem in software development called "dependencies" and has been solved like in a million different ways. Why is that still a problem with the architecture?
I think it is a mental problem, not a technical one.
Properties of a system's architecture
We can reason about code. We can spot code-smells, review the changes being introduced, and all that corpo-nonsense we do to make sure that even if this is the one day in your life you were not thinking straight, there will be someone watching your back. That's how professionals do things.
But that means that if you think about architecture as part of the code, then for example, introducing a dependency on another system shouldn't be the architect's decision. It should be the architect's initiative before anyone even started asking about it.
Let's get technical
So, I hear you say: "if architecture is in the code, does it mean that it can be refactored?". And the answer is obviously a big, fat "Yes!". The only difference is that, on that level, you don't deal with concrete classes and direct inter-object relations. You deal with subsystems, concepts, lines of inheritance and inter/extra-system communication rather than discrete implementations of some subsystem's internal caching whatever.
That means that there does not exist a generic programming language that would be "for the architects". There are concepts, architectural guidelines that indeed can and always are implemented in a general-purpose language, but it's often so convoluted that the meaning of it is completely lost in the mud.
That is a sign of bad architecture.
Refactorings
Here are some examples of refactorings that I would put in the "architectural changes":
- extracting a separately hosted service from another application
- moving a responsibility from one hosted service to another
- removing dependency on a service
- sunsetting services
- introducing a range of services with a common theme
- refactoring services to line-up with a common theme of other services
- maintaining service lifespan
Now imagine there's a developer, that has a library that has named exports and proper in-line docs, and he'll just interact with those classes. They will indeed do the architectural things, like spawning new services and the like.
Now imagine that developer being is asked to introduce a new type of service the company just produced/bought. It has a foreign interface, so you use the design patterns at your disposal to connect it to the rest of the system.
It's still coding. It always have been. It always will be.
No matter what everyone else will tell you.
It's just the libraries are different and sometimes things are better expressed using a DSL or as a graph of objects (say a yaml file) than code in some "proper" programming language.
But it is still code. It needs to be maintained. It needs to be kept on-par with what the rest of the project needs. And if something's is wrong with it, it needs an architect to fix it. And believe me, once you realize that all that is just code, you won't believe how many refactorings your architecture will need and how much more effective your teams will be!
Closing thoughts
Having said all that above, I think teams leveraging a coding, in-team architect stand a much better chance of success. Not only will the rapid response force be there all the time when you need it, but your other guys will have someone to learn from, to guide them. If you only allow your "best guys" to dump a truck load of horse manure on the devs and leave, don't expect them to eat that shit and be happy about it.
Happy coding!
Inspired by https://www.youtube.com/watch?v=9A9ZxIrc9CE
Top comments (0)