Simple rules for keeping dev teams out of trouble

I’ve been leading small software development teams on big projects since 2004. Painful experiences taught me some simples rules to make it less painful. Here they are, presented in order of discovery:

      1. If it can be null, it will be null
      2. The clipboard is a cruel mistress
      3. Size really does matter
      4. Inside every small problem is a larger one, struggling to get free
      5. Every bug you fix creates 2 more
      6. The law of the motorcycle shop is non-negotiable
      7. Cleverness is the mother of regret
      8. Just in time requirements are neither
      9. Don’t solve problems you don’t have yet, Nostradamus
      10. Later == never, temporary == forever, shipped > not shipped
      11. Only change 1 thing at a time
      12. Always redo, never fix
      13. Finish the most important feature first
      14. Tomorrow you hates the code you write today, so don’t plan too far ahead
      15. Character data is nvarchar(max) until you can prove otherwise (see rule 2)
      16. Schrodinger’s Spec – you can know what the client wants, or what will be best for them, just not at the same time
      17. Solve the toughest problem first
      18. Legacy == proven. Try out the newest thing on your own time and dime.
      19. Naming stuff is hard
      20. You’re not going to reuse that
      21. Process: never fix, always redo. Code: never rewrite, always fix
      22. Fix problems upstream
      23. Never use a black box when a text file will do
      24. I will put my strongly typed boot up your loosely coupled [redacted]
      25. The original sin of code is writing it
      26. An unbound task is the Devil’s workshop
      27. Developer time is vastly more expensive than CPU time

Cloud Skeptic #0

Split your codebase, split your teams, create a lot of opportunities for mediocre coders to grow into mediocre engineering managers, everybody was happy. Including your hardware vendor, because suddenly you needed much more hardware to run the same workloads… The feedback cycle is truly broken – testing a microservice is merely testing a cog in a machine and no guarantee that the cog will fit the machine – but we just throw more bodies at the problem because Gartner tells us this is the future.

Cees de Groot goes Back to the 70s with Serverless.

And the Rule 17 Lifetime Achievement Award goes to…COBOL

The sheer age of those COBOL systems is, oddly, actually something that works in their favor. Because they’re old, they have been relentlessly debugged. When a program is first written, it inevitably has problems…But those COBOL programs that run the world? They’ve had decades for coders and users to uncover all the problems, and to fix them…They’ve been debugged more than just about any code on the planet. This idea — that older code can not only be good, but in crucial ways superior to newer code — is at odds with a lot of Silicon Valley myth making.

Legacy == Proven.

Clive Thompson on the enduring fitness and necessity of COBOL https://www.wealthsimple.com/en-ca/magazine/cobol-controls-your-money

Cleverness is the Mother of Regret

Scott Locklin on the wisdom of rules 6 and 17

One of the valuable things about popular but boring languages is that the code has been traversed many times, and routine stuff you’re likely to use in production is probably well debugged… The other benefit to boring languages is people concentrate on the problem, rather than the interesting complexities of the language itself.

https://scottlocklin.wordpress.com/2021/01/08/woo-for-its-own-sake/