If you're looking for help with C#, .NET, Azure, Architecture, or would simply value an independent opinion then please get in touch here or over on Twitter.
Nor does SCRUM.
Nor does XP.
Nor does waterfall (I could keep going with the methodologies).
Nor does unit testing.
Nor does acceptance testing.
Nor does the runtime you are using.
Nor does the version of a framework you are using.
Nor does your automated deployment process.
Nor does the language you are using.
Nor do the patterns you are using.
Nor do those post-its you’ve put on the wall.
We get so worked up about these things on Twitter (and boy do we get worked up) but they are all intrinsically valueless. Utterly valueless.
What gives them value (positive or negative) is context – your goal and your constraints. To illustrate this I’m going to use three examples from my career.
As far as my public persona goes this is largely what I am today. My goal and constraints are pretty clear: I want to have fun, there’s only me and limited time, and I only want to spend hobby levels of money.
In many ways I’m back where I started with my BBC Micro. I have an idea, it appeals to me, and I just crack on and have a bash it. Sometimes the focus on satisfying my curiosity, sometimes its making something I will use, sometimes its making something I hope others will use. I don’t have to talk to anybody about it, I don’t need to make money, I’m the customer / customer proxy.
This being the case I’ll use a toolchain I think is fun and the most complex process I’m likely to have is a Trello board, but mostly not even that. I might add a unit test in if it helps me. I’ll probably do an automated deployment process because the things I do are simple enough that its really just “build and upload”.
I really just make day to day decisions based on what will amuse me.
The phrase “next paycheck delivery” was used in what I think was a pejorative manner in a reply to one of my tweets earlier today but actually next paycheck delivery (much like code) has no value in and of itself and can be either good or bad depending on your context. I’ve spent time in a number of startups where actually that was entirely the right thing to be doing – without the next paycheck the company was going to sink.
In the specific example I’m thinking of the business needed to pivot and had very little runway left. We had to attract customers and fast and they wanted to see something working and be able to use it.
So our goal was clear – get a working, usable, demo for a customer. Our constraints: we had an insane deadline, no money, and there were two of us.
We sketched out a plan. Minimum possible set of features based on what would be useful and what we thought it would cost to build. We divided up the work so we could do it in parallel. We wrote no unit tests. We used the most bare bones of process (you do this stuff and I’ll do this stuff). We threw things together in a fairly ramshackle way based on how each of us could move fastest. We were not gnashing out teeth about what version of runtimes we were using. We reused some bits in a different language that had issues but would serve our purpose.
It was so down to the wire we were doing the proverbial “coding while the customer was watching”. Put simply: “I ain’t got time to bleed”.
Did this cause a problem for later down the road? Yes. Absolutely.
Did it enable the business to survive? Yes. Absolutely.
Would it have been better not to end up here? Yes. Absolutely.
Is it code I was proud of? Yes. Absolutely. It met its goal.
I’ve been involved in a few more startups and super constrained environments since and I’ve got a lot better at moving fast and ending up with something that is easier to move along and develop.
If you find yourself here the important thing is to recognise that yes you’re likely building up debt for the future, try to minimise that, understand that at some point yes you may enter rewrite territory.
Large organisation, established products
I’ve also spent time in larger organisations doing various roles – I think the biggest had 50 development teams and it was an environment where, at the wrong time, mistakes in some parts of the system could cost millions in minutes.
The company had market fit, it had customers, it was still growing rapidly, it had complex integrated systems and services, and a physical presence. It didn’t matter if teams did things differently but there were economies of scale that came from solving similar classes of problem in similar ways (why generate unique DevOps pipelines for two .NET API services for example). But what was really hard was co-ordinating all this. Sure we could use versioned APIs, contracts etc. but delivering a significant new piece of value required the delivery from several teams and co-ordination with the physical aspects of the business.
Goals and constraints would change but to focus in on just a handful of key things that were common:
- Predictable delivery
- Common understanding of contracts
- High quality
As a result we had people focused on service integration and standards, teams followed agile processes (there was variance between the teams), there were two or three runtime environments but some basic conformance standards, a lot of focus on both unit and acceptance testing, formalised roles, code reviews, architecture reviews, discipline specialists, etc. etc.
These things worked for this organisation – in the context of the organisations goals and constraints they added value. “We’re not at home to Mr Cockup”.
But the practices they found essential would have crippled the startup trying to pivot.
I provide these examples hopefully to illustrate that its all about context. For me understanding this is what sets a good developer apart from a coder and its vital to engineering management.
To finish in the pithy tone in which I started I just have a few recommendations really:
- Always make sure you understand and can clearly articulate your goal
- Always make sure you understand and can clearly articulate your constraints
- Always make sure you understand what success looks like and how you will measure that
- Always make sure you understand what failure looks like
- Always make sure your approach is based on maximizing your outcomes within those constraints.
- Have an eye on the future but don’t let it impede your today – the future may never come if you do.
- Relentlessly focus on value – but remember that value is related to your context and not what some dude told you on Twitter.
- When someone tells you technology, tools, practices have value in and of themselves – they’re probably trying to sell you something.
- Do not, I repeat, do not become an evangelist unless your job is to be an evangelist. The minute you do you’ve lost objectivity.