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 (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

No comments:

Post a Comment