Solution driven design

When I was much younger, I used to have a chess tutor. My strategy and analytical thinking sharpened tremendously during that period and I learned a lot of things playing chess, at the end of the day there were a couple important lessons I took away from my teacher and the game that have transcended chess and I use in my life as guiding principles for other things, and one of them is:

Never make a move JUST because it is your turn to play.

Thinking about it, this sounds like a quote from a Kung-fu movie and similarly to quotes from Kung-fu movies this sounds very simple to do, even sounds like common sense but it is quite hard to obey. It requires discipline and a certain level of attention to the game, there are times in chess when you are still figuring out your attack and your opponent has not matured their attack enough for it to affect your game and ANY move on the board seems adequate...false! Basically what I got from that advice was that you should ALWAYS have a have a plan, you should always have a reason for an action. Every action you take on the board is a baby step towards a checkmate, from the pieces you choose to defend your king to the pawn you advance an extra step, nothing should be done solely because you can.

When it comes to designing software systems I have found that this principle works. The aim is to design a system that every single part and every single feature is in support of a greater goal. Adding a feature cause it is just one extra line of code or because it is dope and shows off your team’s technical skill is usually a bad move. Creating a feature that is dope and shows off your technical skill can be good if you are creating open source software to share with a community that you want to market yourself and your team to (If your solving a marketing problem). Every software design should be trying to solve a specific problem in a specific area, you just need to be very clear to yourself and your team what problems these are and stick to solving only those.

Similar to the chess principle this seems like common sense till you are actually in the battlefield coding out solutions and one of your team members says "You know if we add feature X and add animation Y to this product, those developers in team Z are gonna piss their pants when they see it"! Temptation comes knocking!

Design is not just what it looks like and feels like. Design is how it works. - Steve Jobs

I resonate a lot with Steve Jobs quote above because when you truly understand that design is not simply the look of a product but also includes the inner workings, the flow and the way the way all the pieces of the product come together. You realize every line of code you write MUST be a solution to a very specific problem, a well defined problem that has been decided in the requirements of your product much earlier, following this, you will then start to design systems that are cohesive, that tell a singular story and are great at solving that particular problem. You start to see that the UI becomes intuitive, the app is easier to extend later, almost like your past self could somehow see the future. Staying true to this will produce lean and impactful products.

"Tzu-li and Tzu-ssu were boasting about the size of their latest programs. ‘Two-hundred thousand lines,’ said Tzu-li, ‘not counting comments!’ Tzu-ssu responded, ‘Pssh, mine is almost a million lines already.’ Master Yuan-Ma said, ‘My best program has five hundred lines.’ Hearing this, Tzu-li and Tzu-ssu were enlightened." -Master Yuan-Ma