Almost everyone I know in tech does not think of tech the way that I do.

And most people I know in tech would do something else, if the money was better.

Most people seem to hate their job in some way. Not the people, but the job, the pressure, the stress, and the constant nature of that stress.

I’ve been involved at senior and leadership level in developing or supporting the development of many many applications for companies and organisations ranging from the very small to very large including for Governments and some of the largest orgs in the world.

I’ve been doing this at this level for around 2 decades.

I’ve learned a huge amount about what should be done and what should not be done. If there’s one thing I can tell you, it is that I will change my mind again about what I write here at some point in the future, because tech does not stand still.

Maybe there’s a way to put some principles in place that can improve how we do tech that benefits the people that work in it, and still delivers the necessary solutions.

Here are some principles, or guidelines maybe, that I think can help do this:

This may seem to be obvious, but it’s not.

The idea of “customer need” or similar is in pretty much every project/product management mantra/framework/practice I can think of.

But there is a difference between thinking you understand your customer‘s needs and actually knowing that the customer has that need.

It’s much much harder to know.

“What the need is” is almost always ignored, or considered to be “clear and unambiguous”, until well after development of any solution has started.

Very few people in tech actually do this properly.

Everybody says they do this, but what most people actually do is guess, or assume the need from their own bias, or from minimal interaction with very few customers.

Identifying needs properly takes a huge amount of effort. Much more than most companies put in, and often the effort put in is expended in an attempt to confirm the bias that already exists.

Building the wrong thing can be very demoralising. Start here if you want to make people who work for you happy.

If you cannot clearly identify a customer need, then you cannot define the solution that you need to create to meet that need, and you shouldn’t start anything until you do.

You wouldn’t believe how obvious this is either, and how often this is either missed, or what happens more often, the solution that is created is far more complex than the need is, and can create additional needs that were not there to start with.

An example is useful here:

At one of my previous startups, the marketing team were struggling to get the right data out of our analytics. So I sat down with the Head of Marketing (one of the other 4 people in the startup) and worked out exactly what they needed. They needed CSV files corresponding to a specific set of queries of the data. They needed these CSV files every morning and they needed to correspond to the previous midnight to midnight (UTC+0) timespan. In previous startups, I would likely have provided them with a simple web interface, with a username and password and everything else that goes with it (which would have been relatively easy to do but a pain to maintain). However, we were already using slack, so I created an AWS Lambda function to generate the previous 24 hours data on a schedule during the early hours, and saved the data into S3. I then sent the data in S3 in a slack message to a slack channel only available to the Head of Marketing and myself. He then downloaded it every morning into Excel. This was our marketing process for extracting data from analytics for 18 months with only minor tweaks to the queries needed over that time. The Head of Marketing was ecstatic because it was immediately available to him every morning and he could do whatever he wanted via Excel without worrying about deleting data on a shared drive or similar because it was saved and in S3. It could also be recreated without issue if needed.

This is an example of meeting the need, and only the need.

Maintaining that solution was very straight forward. The amount of code was limited and there was no running server. The Head of Marketing could get his data every day and could even leave it a few days if needed because the data didn’t get deleted (until archived months later). The solution lasted 18 months because we figured out the specific need before doing any delivery work.

If I’d provided a web interface, I would have been on the hook for managing and supporting a web interface, including the underlying server (or serverless implementation) and the security implications that authentication and authorization on a web server requires for that kind of solution. None of that was required.

People like to build simple things. It’s usually quicker and easier, and the response is often more joyful.

Win-win.

Understand and meet the need and only the need.

Most tech people, when they look at a new project, will consider how long the initial build will take. This is generally based on experience of how much coding is involved, how good they and the team around them are, and how complex the logic of the application is.

What almost nobody is good at is understanding the level of maintenance required for the solution once built.

One of the biggest frustrations that I have when talking to people who have worked in tech for a long time is that they believe that the “maintenance“ aspect of a solution is almost a “tax” on a project. It’s just something that has to be paid, and there is no way of minimising that tax.

In other words, if you build any solution and it has X lines of code, then you’re going to need Y humans and Z days per month simply on maintaining that solution.

The idea that maintenance is “baked in” seems to also get worse among people who are advocates of “never-non-open-source” (those people who constantly say that open source solutions are the best and the only ones people should ever use).

Reducing maintenance time is a fundamental good in every single project, and if you can prove that increasing the amount of initial build time is very likely to achieve a reduction in maintenance then longer builds are a reasonable price to pay.

Let me explain:

(These graphs are idealised and not based on real data so don’t come at me, and are intended to help explain the point)

The area under the graph is Total Effort.

It’s pretty obvious to me which one is better over time.

I am not saying that maintenance is never needed, or that maintena