Context in Software Development Advice

Previously I wrote about big companies not using Ruby, Scala or similar new languages because they are not mature enough, adding that this probably wouldn’t apply in small companies. This implies an underlying assumption – that big and small companies are different. This might be obvious to most readers, but based on my experience it isn’t to many people I see working in software. Much of the software development advice around is only useful for one type of organisation, although people get hung up on trying to apply it to everyone.

To me, as far as a software team is concerned, a big company is one where there is a sizeable layer of bureaucracy. This can manifest as a large number of political players, passive stakeholders who can greatly change requirements, seemingly arbitrary requirements, or just filling in forms and otherwise jumping through hoops. This is not to say that all of this is unnecessary – some degree of bureaucracy is required to stop developers going off on complete flights of fancy. Also government regulation often requires development to follow a set path; a developer doing their own thing could unknowingly expose the company to sanctions or lawsuits. There seems to be a correlation between the traditional measures of a big firm and bureaucracy (employees and revenues), but they don’t always align. I have worked for a very profitable 50K+ employee firm and been allowed to do largely as I wished. While at a 50 person startup in a highly regulated (and litigious!) domain, I was drowned in paperwork.

Each system has its own advantages & disadvantages. Personally I prefer working in smaller companies, or at least in parts of large companies that have more of a small company feel. However, far more developers work under big firm conditions, and I have met good developers who prefer the system. So when I read about avoiding corner cases I think “yeah, lets get things done”, but at the same time realise this might not work in an IT department of a large commercial bank. I can also empathise with Eoin Woods about how a Software Architect needs to be able to find and involve all the stakeholders of a project, especially the hidden, passive ones that can stop a project right before it goes into production – a lesson I learnt the hard way. Although, most small firms wouldn’t even need a Software Architect. Obviously the context of the advice is crucial.

Some of the best advice I ever received in software development was while working at a small Rational Unified Process consultancy in the late 90’s. The RUP is a large and detailed beast often favoured by large companies, although the consultancy successfully applied it to many clients large and small. This was done by never straying from the spirit of the process, but very regularly deviating from the written word of the process. I remember one of the owners there telling me the first step of the RUP on a project was to work out which bits of it you should throw out as unnecessary (the implication being that most of it would be bypassed).

Basically, there is no silver bullet. Advice is just that, advice. Think about how the advice fits your situation – what are the premises, and don’t just blindly follow it. I think software projects work best where they are done by people who look to understand their environment and can adapt – not just retrying the same old thing that worked last time (for you or someone else).