Your software ecosystem can quickly add new features while maintaining good software architecture

Be an investor, not a hustler

I have observed many developers who are brilliant technically, who can write good code quickly. But I’ve also observed that, over time, these developers’ work gets slower... and slower.

These are what I call software hustlers. They go go go go, and they get the job done… until the code is in such a mess, it's impossible to unpick one module from the next – a very expensive mistake.

To avoid becoming a hustler, it’s a good idea for all developers to apportion some of their dev time into good architectural decision-making. Unlike investing money, though, you shouldn't maximise this time. Instead, you need to invest enough 'architecture time' to be effective, but not so much that your project deadlines start to get missed.

Solving the wrong problems slows you down

I find it fascinating when founders talk about a new 'Facebook-sized app idea' but then start discussing the software stack.

If your idea is of that size, the app can be created in one of a hundred technologies. The real conversation should be about the servers, the network, the data centers, the redundancies etc. etc. that make the app possible.

Ideas are fabulous. But along with the ideas, we need executable plans highlighting the problems we are solving today.

Having said that... SHIP SHIP SHIP to the users

The two points above are about strategic programming and thinking. They are vital.

Equally vital is deploying new features and maintaining/improving existing features for your users.

Creating beautiful code will get you a thumbs up from your team. But the users who pay for the bills, the salaries, and the Christmas parties don’t care about the code; they care about the features.

So, once we are clear on how much to invest in architectural decisions every week, it’s time to deploy code like a maniac. Maniacs are fast. And substantial.

The 80/20 rule is more important in software development

If you search for a book on 'Software APIs,' you will be faced with hundreds of options. This is not a bad thing for an important topic like APIs.

The same cannot be said for the tens of thousands of books on unimportant topics.

The landscape of software books is a representation of what people are learning, but how much of it is important, useful, and executable?

This isn't an easy question to answer because everyone has different needs.

Therefore, developers’ main job is to quickly identify the fundamentals for their unique situation. Double down on them. And ignore the noise.

Pro tip: popular != important.