Like most people, I've worked with some pretty ropey codebases over the years - in fact I'm big enough to admit that I've created or contributed to some too. However, I'm no longer phased by it in the way that I might have been 10 years ago. 'Legacy code' is merely a fact of life that as professionals, we have to accept - and dare I say it - embrace. It's not that I enjoy working with legacy code any more than the next guy, it's just that I have a good appreciation of how 'less than perfect' code is generated and a trusted bag of techniques for making it better.
Developing a software product is always a collaboration between the commercial side of the business and the technical people with the capabilities of implementing the business vision. Companies at different stages of maturity have different requirements, expectations and Goals. Dylan Beattie has written several posts about Conway's Law - which distils down to something along the lines of: companies will always build 'systems' with a structure that reflects the structure of their organisation - and many of you will have seen it played out in the places you have worked.
It was a very impressive observation when first published 50 years ago, but I find the more disappointing side of it is that it still holds true in far too many cases, despite the efforts of the professional software movement to try move in other directions. I'll do another post in the future looking at some of the reasons for this, but for today, I'm going to focus on the small start-up.
Start-ups can be immensely fun places to work - I'm working for one at the moment and have no problems getting out of bed in the morning. The goals of a startup are typically laid out by whoever is bank-rolling the first phase of the company's life. It's way too simplistic to say that startups exist to turn the founders into a millionaires with nice houses, fast cars and a holiday homes dotted around the globe. Often, the founders already have that. They're serial entrepreneurs who live on the thrill of the gamble and the desire to create something new, better or disruptive. They're typically also smart enough to see when an idea is not working and the plug needs to pulled.
The goal might be simply to try something out and see if it flies. It could equally be taking an existing idea and making it much better or re-booting the whole concept. Visionaries with particularly large bank balances will operate differently, but fundamentally, they are all taking a significant amount of risk.
All good organisations should try to minimise waste, maximise productivity and deliver something good to the customer as soon as possible. To me, this sounds a lot like agile. However in a tiny startup, even agile can be too heavy, too prescriptive and too guilt laden. *Every* decision about tools, process, people, equipment, approach, design, architecture, documentation and so on, has to be looked at through a magnifying glass that is focusing the needs of the business at that point in time with half an eye on the future.
When you're part of a large and successful organisation, as a developer, you might have a minimum acceptable criteria for all the above that are simply non-negotiable. In the melting pot of a small startup, you will have to compromise on any number of things. Not forever, but until, in the eyes of the business, the benefit is justifiable.
So here's an extreme (but not uncommon) example:
Tech: "As a software team, we must base our product on a fully unit tested core and have continuous behavioural testing from day one so that we can iterate really quickly and deliver rapid increments to our customers"
Business: "We need a first cut product ready as soon as possible. If we don't have customers, we won't get further funding, the money will run out and your continuous behavioural testing will look like the suckiest decision ever."
Not all techies are happy to work in this sort of environment, but personally, I find it interesting, refreshing and it really helps the company to focus on small, continuous improvements at the right time. My current role is not agile - it's probably not even lean - it's more at the 'light' end of lean without being out and out hacking. Good people are the key in this scenario, and working with a small handful of other guys who I trust really helps.
When I started, most of the system as it stood at that point in time, had been written by one guy. There was no CI process in place, documentation was almost non-existant and unit tests were "on the desirable list". However, the system fundamentally worked and had been stable for a little while. For a lot of devs, this would seem like the nightmare scenario. For me, it was just something that I could get my teeth into and add a lot of value in a short amount of time.
We are still a long way away from where I'd like us to be in terms of process, and almost on a daily basis, I have to prevent myself from biting off too big a problem and trying to fix it. The challenge of this role is going to be all about doing the right thing at the right time... in small, controlled iterations that produce big visible benefits.
My next post will start to explore some of the reasoning about the things I've chosen to do, and those I've chosen to save for later.
No comments:
Post a Comment