Tuesday, November 19, 2019

How to architect your system for the future.

A frequent but toxic approach to system design you will frequently hear parroted by MOST non technical business people and a disturbingly large number of technical people is 'future proofing design' or 'designing for the future'

Future proofing your software is not actually one of the available options, not until time travel gives us a definitive window into the future and even then, attempting to future proof your software would still not be a very good idea/approach.

The reality is that your needs today will be different from your needs tomorrow. Given this reality, you are faced with either designing a system today that's most optimal for today's needs or have a system toady that's most optimal for tomorrow's needs, but suboptimal for today's needs. What you can't do is design a system today that's optimal for both today and tomorrow, and attempting to do so only lands with you with the third option - a system that's suboptimal for both today and tomorrow's needs. This is what attempts at future proofing ultimately get you.

Future proofing is a sentiment expressed by people with the wrong disposition. A disposition that has already resigned itself to the 'fact' that the engineering team is unable to effectively change and adapt software, which is kind of absurd considering making changes is quite literally what engineers do.

The correct approach is to build a culture that isn't resistant to change, but rather one that embraces it early and often. A culture that frequently and comprehensively re-evaluates the current system vs business needs and sees what needs refactoring and re-architecting. A culture that keeps track of fundamental assumptions made and when evolving business needs inevitably violate said assumptions, lean into this change and happily pay the price of making the necessary architectural changes to the system required to accommodate the new world, rather than hacking together some Frankenstein monster that puts your organization's system on a path to irrelevancy (the dreaded re-write).

Thursday, November 7, 2019

Leadership Philosophy

I've been a tech lead for several years now, and I'm often asked (at interviews or general discussions) about my leadership philosophy. The running joke in places I've worked has always been that I run a tight ship - but this while true, can often be misleading.

It's true - my software projects have always met deadlines and always had some of the lowest bug per release rates of the places I've worked at. Some may jump to the conclusion that do this my dictacting the every move of my development team, which couldn't be further from the truth. Far from it, all the developers that have worked on my systems will readily tell you that they have enjoyed more individual freedom working under me than they did most anyone else.

How do I achieve this? Simple I focus on and create an extreme culture of accountability around the what, not the how. What I want is simple: robust maintainable software that conforms to spec (functional and performant) delivered on time. How individual developers achieve this is their concern, and while as lead I'm always willing to suggest ways to improve on quality and speed of an individual developer (hello vim..haha) I'm certainly not overly (or much at all) concerned with individual preferences. Focussing on HOW they deliver their code is micromanaging. Yes it is. Insisting on pair programming? Micromanaging. Insisting on TDD? Micromanaging. The worst thing about micromanaging (apart from the fact that everybody fucking hates it) is the fact that time spent focussing on the unimportant (the how) is time spent not policing and focussing on the important (what is actually being produced).

Look TDD is awesome  - I find it is especially useful in making me focus on requirements and not code when writing tests which is pivotal when writing quality tests. However, if a developer is giving me quality code with well written tests without using TDD, why on earth would I force them to use TDD?

It's important to differentiate things that constitute individual working styles/process and separate that from (and focus on) the work they produce. Try as little as possible NOT to dictate personal process - it's not just that it's not helpful, it's often counterproductive.

Now if a specific developer is failing to meet clearly defined team standards e.g unacceptable number of bugs introduced by said individual, failing to meet deadlines, failure to write proper tests, code not meeting specs (all things that you should be religiously tracking on your team) - Then and ONLY then should you sit down with said developer and go over their process insisting on changes that you feel would result in better software.

How to architect your system for the future.

A frequent but toxic approach to system design you will frequently hear parroted by MOST non technical business people and a disturbingly la...