Organising for Failure

If you’ve assembled an A-Team of nutcases, failure is pretty well assured. However, you may not have been so lucky. Perhaps you’ve been lumped with an existing team of engineers who are half-decent. Well, not to worry. There are a myriad of other ways to muck it all up. As any fule kno, development works best if you have a small team crammed tightly together, ideally in a garage. Bureaucracy is at an absolute minimum, everybody knows what they’re meant to be doing and has the delegated authority to do it. Management structures, so far as they exist, are simple and streamlined. Having noted that ideal, your goal is to get as far away from it as possible. You must mount a sustained attack on collaboration, simplicity, cohesion and autonomy. Charge !

Bums on Seats !

First, expand. Expand hastily, and on the basis that Quantity = Quality. It’s rarely difficult to pitch this idea to your leadership team, especially if they’re in a hurry to get a pet project finished. Clearly a team of 30 will do the job three times as fast as a team of 10, and if you can recruit all 20 over the next three months you’ll be over twice as productive for the year as a whole. Stands to reason. Look at the numbers. The board will be wowed by your can-do, punchy, aggressive attitude to delivery. This is now your big chance to dilute and depress your department’s software batting average, using the IT Shambles sure-fire patent Five Step approach. Even if you pick up one or two good people by accident, the sheer volume of recruitment will ensure they are brought up to speed only slowly. If you’re lucky, their good work will be lost in the confusion and they will resign early.

If anyone mentions the Mythical Man Month, have them bundled into the back of a transit van, driven to a nearby gravel pit and beaten soundly.

Golden Boys

Having recruited the requisite coachload of plodders, crackpots, ideologues and loose cannons, put them in charge. Apart from their own low output, the other great advantage these merry mavericks have is that they can effectively suffocate any residual productivity you may have lurking around elsewhere. Use them to swamp, surround and demoralise the able people you have inherited. Have them produce architectural frameworks and standards which must be adhered to. Place your original, knowledgeable developers at their service, reviewing their code, fixing their bugs and writing documentation for them. Say you’ve got one poor sap actually producing worthwhile code. Get her to run her designs past a committee of mavericks with daily review meetings. She’ll never put a line of code live again.

If your new squad have better pay and conditions than your existing staff, this will speed up the demoralisation process. Your Golden Boys could perhaps be recruited as contractors on rates that amount to twice what your most valuable permanent people take home. Maybe they could be given all that cash while working just four days a week. What you need to create here is a useless, superfluous, unaccountable technocracy with rewards and power aplenty. Make sure any blame and hard work is lumped onto your old timers, now reduced to a dispirited and exploited underclass of code monkeys. You could call it Software Feudalism.

The Development Department on which the Sun Never Sets

To really finesse the Bums on Seats move, you need to get into outsourcing. Again, an easy sell to senior management as all Big High Building Companies do it, so it must be a Good Thing. And it’s apparently cheap. You can assign a human wave of developers to your project for a few quid / euros / coloured beads. To get the best from this gambit, pick a number of outsourcing partners, and make sure they are all in different timezones with different native languages. Never English. This can be sold as a “best-of-breed” strategic coup – use the well-worn French chefs / German mechanics / Swiss managers / British policemen gag to clinch the deal. Then exercise absolutely no quality control over the people your new “partners” shove into your project. For complete paralysis, the software development lifecycle should follow the sun, but not in a straight line: analysis in Uttoxeter, design in Vladivostok, development in Rangoon, testing in San Salvador. And the end users, inevitably, in Ankara.

Your Mongolian outsourcing partners, yesterday. Heading to a design review, and then to pillage Budapest on the way back.

One Big Team …

It’s never the ideal, but multi-country development turns out alright, sometimes. The most workable variant has each office operating pretty much independently with complete control over a distinct chunk of the system. If the interfaces between those distinct chunks are small, clean and relatively well-defined, and the chaps at each end strive to make it work and help each other out, it can be OK.

The antithesis of this sensible, best-of-a-bad-job strategy is the Transglobal Free-For-All, and this is where you can doubly finesse the Bums on Seats idea. In sidestepping any lingering potential for success, your key phrase will be One Team.  Run your geographically diverse software development enterprise as a single inter-continental unit. Work on all parts of all systems simultaneously at all sites. Everyone is dependant on everyone else, no-one has ownership, no-one has responsibility. For 24 hours a day, 7 days a week, any line of code can be edited, queried, re-edited and finally fouled up by any one of 97 clueless numpties scattered across the planet.

… or Lots of Very Small Teams

Placing the palm of your hand on a hot electric iron is daft. At the other end of the temperature scale, sticking your fingers in liquid nitrogen is not to be recommended either. In fact, we often find that the diametric opposite of one terrible idea is one equally heinous. So instead of one team, why not have dozens ? Split responsibilities as finely as you possibly can. The organising principle here is that an engineer can only understand one thing – one language, one operating system, one DBMS and (crucially) one sub-system and related piece of business logic. If you’ve done your job right, a development of any size will need at least eight disparate teams to work together and agree interfaces without confusion or conflict. If you’ve put your loonies in charge and the teams are physically and culturally remote, this will be nigh-on impossible.

To head off at a slight tangent, I have to say that this logic extends beautifully from software to infrastructure, where it can have spectacular destructive power. Suppose you need to connect web server X in site A to database server Y in site B across the internet. If you’ve got the wafer-thin cheese-slicing just right, you will need to mobilise the Unix, networks, cabling, telecoms, firewalls and Sys Admin teams at site A, and all of those plus the DBAs at site B. See ? That’s 13 teams in all, each of which has different management, practices and priorities. It could easily take 30 different people, 120 emails and 200 phone calls over six months to perform a task that one or two competent engineers could complete in an afternoon. You will have noticed that some of the team names seem to duplicate others. Surely the Unix team do the Sys Admin on Unix boxes, and isn’t cabling the same thing as networks ? Well, Yes, but to quote Elton John, then again, No. Hard, sharp, concrete-reinforced borders between very closely-related activities is at the heart of this notion. If you can persuade your bosses that you need one DBA team for stored procedures, another for permissions, and a third for schema changes, then you really are cooking with gas.

The Best of Both Worlds. Shangri La Glimpsed From Afar.

There may be somewhere a software shambles Guru who can combine the technical chaos of One Team with the organisational nightmare of Siloing. This has eluded me so far, but could be the Golden Bullet we need to stop software production for ever. Both are easy to argue for. Nobody likes the idea of division, so of course we should all be One Great Big Happy Team. And dividing developers into areas of functional expertise seems like sound management. Cars have valves, hearts have valves, but you wouldn’t ask a car mechanic to open you up and sort out your tricuspids, would you ? By the same token, how could a Java programmer be expected to write a bit of C or a stored procedure ? Stands to reason.

If you’re a gibbering bloody eejit on crack.