Tuesday, 18 April 2017

What happens if your key developer goes under a bus?

OK, a little morbid I know, but it is a question I am asked on far too regular a basis. "What happens if you leave or get in an accident?" Technically it's called key person risk and is the reason you have teams, good documentation and source code control with non-stop backups. 

Technically I have only left a project twice before I wanted to and before a convenient delivery point. 
  • Large public sector integrated web site, knowledge-base and licensing site. I left 1 month before go-live as the contract renewal negotiations broke down. The site eventually went live 18 months after I left.
  • Geospatial data management system - I left when the scrum master decided they knew more than the architect, about a month before an on target delivery. System still not live 1 year later.

The reality is that you don't survive key person risk easily, it's a huge nightmare and usually puts you back about a year. How to avoid it? Have a happy team that communicates and try not to let too much jealousy creep into negotiations.

Story time:
Once upon a time a large digital consultancy was hired by a multi-billion dollar computer chip manufacturer to create an online game. The brief was that the game should have sufficient difficulty that at the end of 8 weeks a winner could be declared and presented with an expensive gaming laptop. The rules of the game were defined by the sales manager as a flying game where the player had to pass various obstacles, the complexity and difficulty of which were beyond human reaction times until the last few weeks of the game.

The project was delayed through negotiations and when it was eventually agreed it just so happened that the star developer who helped the Sales team was on a vacation, his first in 3 years. The sales team decided to hire an external consultancy that they knew and had used before to undertake the work, they did not engage with the in-house engineering team, preferring to keep all the details in one place.

When the star developer returned he was reserved to undertake due diligence on the progress from the external consultancy (part of the ISO27001 quality assurance the agency had.) He asked for the brief, the backlog, the progress against plan and a login to the code repository. It turned out there were a few missing items, notably:
  • There was no brief (it was verbal and conducted in 'brainstorming' sessions)
  • There was no backlog (The sales team simply reviewed the prototypes)
  • There was no plan (The sales team simply set a deadline)
  • There was no code repository (The developers did everything on their laptops)
There was however a working prototype and a copy of the code from 1 week previously. The prototype would work as long as you did not use the controls, it was an early prototype demonstrating the visuals of the game.

The Star Developer called a meeting with the sales team and expressed his concern, raising warning flags that in his opinion they were unlikely to meet the deadline some 6 weeks away, however the sales team had confidence in the external consultancy as the lead salesman only lived down the road from the consultancy, which was run from a converted Victorian house in his street. The Star Developer asked to be included in the next review at the end of the week and asked that the consultancy be informed that a code review was required.

The end of the week came and the external consultancy had to cancel the meeting due to unforeseen circumstances, the following week came and went with no submissions. The sales team where not worried, the prototype was nearly there weeks ago, and there were 4 weeks to the deadline, it wouldn't take long to test surely?

The in-house testers had not written a test plan as there was no brief, after a 1 week of discovery they estimated 2 weeks to write the scenarios and 4 man weeks to test them.

The Head of development called a crisis meeting, attending were:
  • 2 of the sales team
  • A representative from the external consultancy
  • The Star developer
  • The Lead tester
  • The Head of development
At the crisis meeting the external consultancy relayed a sad story. I turned out that their lead developer had been involved in a road traffic accident, he had been hit by a bus whilst cycling to work.

Not to worry, the Star developer was now available, if the consultancy simply supplied the code completed to date, they would complete the project. The external consultancy explained again that their lead developer had been involved in an accident, he was still in hospital.

The Star developer explained that he would be able to continue the work, all he needed was the code completed to date, the external consultancy explained that their lead developer was travelling to work with his laptop, which was destroyed in the accident. The laptop contained the only complete copy of the code.

The development was brought back in house and an attempt was made to continue from the submitted prototype, it turned out that the game parameters had not been documented or understood; if the user simply shook the mouse long enough then they would win the game. The entirety of the codebase had to be thrown away.

The conclusion of the engagement was that the entire project had to start again, the sales team negotiated that the project was put back 3 months and the competition was completed, the engagement still made a small profit but the client rolled future engagements over due to their standard policy of re-competing suppliers every 2 years.

The lessons learnt are numerous and may well be longer that the story, but it does go to prove that if you say "What happens if the developer goes under a bus?" You may get more than you wished for.

Thursday, 13 April 2017

Top 10 tips for Software Development

During a kickoff meeting I was once asked what my Top 10 tips to running a software development project were. Really it's an impossible question, many people have written many books on the subject and made far more money than me in doing so. However here are my current Top Ten Tips for Software Development!

  1. Keep it simple Stupid (KISS) or use Occam's Razor (If there are two explanations for an occurrence, the simpler one is usually better)
    Occam was a 14th century friar who studied logic. The lesson here is, everyone thinks they know better and thinks they thought of it first, but the reality is often much simpler!  
  2. Everyone thinks they have the new greatest idea that no-one has ever thought of before.
    Humour them (See tip 1)
  3. Pick one set of tools and stick to them.
    Ideally everyone should use the same set of tools and there should be as few of them as possible (See tip 1)
  4. A little planning can avoid much waste (James Coplien - Lean Architecture)
    The tip here is don't plan too much, plan enough to get on with the job. Planning too far ahead makes for many assumptions and gets too complicated (See tip 1)
  5. No Battle Plan ever survives contact with the enemy (Helmuth von Moltke the Elder)
    Often misquoted as Dwight David Eisenhower, Napoleon and George Patton who all thought they said it first (See tip 2)
    Basically, don't expect your plan to work as intended (See Tip 1) Even if you think you are special and it will work for you (See tip 2)
  6. Have a plan *before* you start work.
    Making it up as you go can be fun, but is ultimately doomed.
    See this 1997 Dilbert cartoon
    http://dilbert.com/strip/1997-05-09 (See Tip 2)
  7. Success is inversely proportional to the number of people on the committee responsible for it
    There must be a leader and that person must take responsibility for their decisions (See Tip 1)
  8. A developer tests what works, a tester finds what doesn't work
    Or "Never let a developer test their own code" (See Tip 1)
    There is much written about TDD, Unit testing and automated testing and much debate about what works, ultimately if you change something - test it.
  9. Don't be afraid to ask stupid questions
    If you didn't understand what is being said, there is a high likelihood that nobody else did either (See Tip 1)
  10. The second law of thermodynamics states that the total entropy of an isolated system can only increase over time.
    Murphy simplified this to "Anything that can go wrong will go wrong" (See Tip 1)
    There are 10 basic Murphys laws
    1. Anything that can go wrong will go wrong.
    2. Left to themselves, things tend to go from bad to worse
    3. Nothing is as easy as it looks.
    4. Everything takes longer than you think.
    5. If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong.
      1. Corollary: If there is a worse time for something to go wrong, it will happen then.
    6. If anything simply cannot go wrong, it will anyway.
    7. If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
    8. If everything seems to be going well, you have obviously overlooked something.
    9. Whenever you set out to do something, something else must be done first.
    10. Every solution breeds new problems.
Smith's Law: "Murphy was an optimist."

Others tips that didn't make the Top 10:
  • Deadlines are always closer than they appear
    • 20/20 hindsight is wonderful but useless
    • To quote one of the greatest thinkers of our time: “I love deadlines. I love the whooshing noise they make as they go by.”
    • Approach Project retrospectives with a sense of humour and remember that nobody will remember them in the morning
  • Developers will always estimate too low
    • Sales always take the developers most optimistic estimate and half it to please the customer
    • Agile/scrum says story points are impartial, this is called an excuse
    • 1 story point == 1/2 day
  • There is never enough coffee
    • Every hour you work over 8 hours in a day means 10 minutes rework the next day
    • Working more than 14 hours in a day means everything you are doing is pointless
    • When the excrement hits the air movement device stay late and sort it out
    • Make sure the person responsible for the excrement stays as well
  • Sometimes there is a reason nobody has ever done it before
    • Copying other people's work is fine as long as you use the word paradigm in the explanation
    • History repeats itself (See Tip 2)
  • Noisy teams get work done
    • A quiet team is a team too nervous to say they are wrong
    • Conflict is good as long as it is resolved
  • The customer is never wrong
    • The customer may need guidance
  • "Agile" means different things to different people
    • Take a certified scrum master course, it not just for people who have nothing better to do and it means you will be able to argue from an informed perspective with the Agile Zealot on your team
    • There is always an Agile Zealot on your team who says what you are doing is not "Agile" or "Scrum" - Fire them immediately
    • If somebody at the daily agile stand-up is always 'refactoring' or in a 'Spike' - Fire them immediately
    • If somebody in the Agile team quotes the YAGNI principle - Fire them immediately
    • If somebody says you shouldn't measure Agile - Fire them immediately
    • Agile does not mean
      • Quicker
      • Cheaper
      • You can do the requirements later
      • You don't need to be involved
      • The first version works
  • Beware of Jargon
    • Playing buzzword Bingo during meetings can be fun, but be aware of your audience and give out the prizes after the meeting
    • Always learn the latest Jargon
    • RTFM
  • Garbage in, Garbage out.
  • There is a bus roaming the streets of London waiting to run over your team