I saw that Matt Wynne had been talking on twitter about various acronyms and why SOLID wasn't a particularly good one.


He came up with PONIES instead:

  • P is for people. You're building this code because actual human people need it. Make sure they will find it useful, and that the way you express and model concepts in the code will make sense to the people of the future who might want to change it.
  • O is for objects. Objects are a reasonable way to organise your code. There's a wealth of patterns and information about how to use them well. I'd start with anything by @rebeccawb, or @sandimetz or @sf105/@natpryce. Note: you can still use functional programming ideas in OO
  • N is for Nulls. Eugh! Avoid them like the plague. Learn about the Null Object pattern, then the Maybe pattern.
  • I is for immutablity. It's great. That's one of those ideas from functional programming I said you could use in OO.
  • E is for entropy. It's the law of nature! Your code will naturally degrade all by itself. Accept that your code will never be quite perfect, relax in this truth for a moment, then try and make sure that every day you send it in the general direction of calm rather than chaos.
  • S is for small. Small is beautiful. Aim for small, composable classes, small methods, small API surfaces and a small amount of code in general.


Following on from that, as these things do, Garry Shutler constructed RAINBOWS:

  • R is for refactoring - no one gets it right first time
  • A is for accountability - you do your best work when you stand by it
  • I is for isolation - clear boundaries reduce unexpected breakages
  • N is for networks - communication routes between people and processes are always problematic
  • B is for breakages - let’s not pretend they don’t happen, lean in to making things resilient
  • O is for observability - you need to understand what your system is actually doing to make it better
  • W is for WIP - keep it as small as possible, to minimise time from investment to value delivered
  • S is for shipped - if it’s not in production, it’s irrelevant


And so I felt obligated to go that one bit further and suggest my own acronym - UNICORNS:

  • U is for Understanding what the problem is (not the solution) and why you are trying to solve it.
  • N is for No Heroics - No all nighters or weekends hacking a low quality solution.
  • I is for Idempotence - mutating state unpredictably is a BAD thing.
  • C is for Conservation of Energy (self care) - Work on hard things when you can, less challenging things when you can't.
  • O is for Objects, small, easily testable chunks of behaviour.
  • R is for Reliability - plan for failure and have a plan for how to degrade or recover gracefully.
  • N is for No Broken Builds - Fix the tests, fix the code, fix the environment before moving on.

Expect a TED talk and a book deal to follow :)