Being an Agile Architect so far

Being an architect after doing software development for more than two decades is a strange experience and a very interesting challenge. I love it but the reality of designing and improving existing solutions is a bit different than what I expected. I thought as architect I will be the guy who will push for new technologies and most of the disagreements with developers will be about me arguing for a more sophisticated solution while they would push for a more pragmatic and minimalist approach. Surprisingly sometimes it is the other way around.

Sometimes drastic simplifications are needed of a software is required to make it maintainable, faster, more durable, etc. A good design is a design the team can execute, can be phased and each released feature yields measurable benefits. Therefore often, we must curb our enthusiasm and design a system we can deliver in a timely fashion and improved on it in iterations. Some of my input is about feature prioritization, what to do in what order, what can wait and sometimes, what to remove. Removing things never feels right because software development is an iterative and additive process.

Removing components, features, replacing exotic solutions with simpler and more predictable or cheaper ones is a lot like removing non-essential things to make a demolition derby car lighter and replacing them with an ugly crash cage for durability and pray that no one gets hurt too badly. It is an interesting engineering challenge but also heart breaking because we are discarding features someone else designed and installed.

To continue with the car analogy, I expected to work on something like the Tesla Cybertruck but given what we have I had to adjust my goals somewhat and some designs, at least in the first few iterations of design, look more like a dystopian vehicles worthy of Mad Max movies. It is fine and probably the best outcome we can hope for when using an Agile process. It also allows redesigning and reworking certain aspects of the solution to fit changing requirements.

No doubt lot depends on the organization type and projects you are working for. But if you are working for a market driven one with tight deadlines, and an insatiable hunger for change then be prepared that you will be put in a position that you will have to argue against ideologically rigid practices, asking why we need feature, can it wait until a later stage of the project, etc. It makes me feel weird sometimes because not so long ago, if it were cars, sometimes I may have been the guy who vehemently argued that painting flames on the side panels is necessary and that we simply cannot race with style without it.

I used to deeply dislike people who used the terms KISS and YAGNI and phrases like "low hanging fruit", etc and now I am one of them. Contrastingly my job also requires me to ensure we stick to an approved technology stack, best practices and be a bit rigid and insist on approaches which require more effort from the developers. It may seem hypocritical but it is really about getting things done within the boundaries of the rules our organization and my peers and myself agreed on.

I think companies should set some time aside for developers to experiment with new tech to calm and nurture their inner scientist. I don’t think architects should hug all research projects rather they should facilitate and help evaluating solutions. I think pet projects, PoCs and research is needed because Agile projects can become boring for developers and can feel like working on a factory conveyor belt: stories in, features out, bugs in, fixes out, faster, faster, faster, more, more, more. When this happens engineers will use real products to experiment to keep things interesting. This can lead to more complex solutions than necessary.?