At the turn of the century, Joel Spolskey introduced the world to the Joel Test. We got 12 quick questions to tell if a company is worth working for or if you should start running. Most companies should be 12/12 – if they answer 10/12, that’s OK too, if they answer 8/12. Get. Out. Now!
Behold the ‘Ersin test’. A 2025 update of the Joel test. A lot of it has changed, but four (in bold) of his questions are perfect in their early 2000’s form.
This list is my own, and it comes from 10+ years working on some of the best teams which have delivered great products. You might not find every answer to be yes, but I think most good teams will be 8/12 or better.
What is amazing is that a lot of the vibe from the Joel test hasn’t changed much in 25 years. This stuff is going to be important in 2250 as it is in 2025.
Every team uses source control. It is ubiquitous. You can find teams that do not practice trunk based development, this is a red flag 🚩. At the turn of the century, Joel observed that some teams don’t use source control. In the current age, it’s so obvious it’s not worth mentioning.
No matter the way you ship code, it should pass through an automated pipeline and you should ship changes very frequently to a common branch. Tests/linters/static analysis are important in 2025. If having fun building software is a goal, you should answer yes to this question.
True in 2000, true in 2025, true in 2250. We should work really hard to make our system buildable in one step. Has this gotten harder to achieve? My impression is that more software product teams would answer ‘yes’ to this than ever before. It is a fundamental thing that you have more disparate tools. The amount of stuff you need to keep in your head as a software engineer has grown.
More complexity and disparate systems to wrangle in any given product doesn’t dis-credit the importance of having a one step build.
Working in a small team you have far less excuse to not have a one step build. This is a superpower you really need to go after in small product teams.
A big change since the 2000’s is the shift in responsibilities between engineering and IT operations. We have much more tools and platforms that can be leveraged. Overall this has led to an environment where every startup can have an easy platform for shipping on.
On top of purpose built cloud providers like old school heroku, or new school Vercel – you have a really strong group of open source tools that can be used for building a platform.
You can build a platform without being an old school IT operator. I would recommend people to stick with out of the box platforms where possible, but you can engineer and operate one if you really want, and you should try and do this without separating the engineering and IT operations function.
I recently heard this named as the ‘‘two team bifurcation '’. Having a feature squad and a support squad is an anti-pattern; you should avoid this – especially in small teams and new products.
The team should be close to the customer feedback at all points. Your product designers should actually be on the team. Your sales/support people should be very close to the engineers at all times.
We can build a very strong engineering organisation by putting the voice of the customer as close to the delivery team as possible.
Splitting the customer voice from a feature delivery team might sound amazing but in practice it leads to resentment and a higher degree of building the wrong thing.
There are a ton of good ways to manage this. Screwing this up is catastrophic. Quality of systems trend towards 0, flexibility and velocity grind to a halt. You have metaphorically painted your product in to a corner.
A continuous approach to quality is the antidote. My favourite way to do this is just to be really explicit to the team that you can spend 20% of your time on quality. You can release a feature to customers and you will still get 20% time to improve that code base. You are allowed to tidy the internals of the product as you go.
In 2025 we are about to hit a real disaster on this front, and you can see the early signs of this based on the current vibe coding trend. If you are a traveller from the future reading this blog post, it’s worth a small call out on what is happening. Novice developers are currently ‘vibe coding’ (AI LLM coding) some amazing products into the world. I love this, and I hate this trend. A massive problem with these vibers is that they inevitably hit a wall, assuming you can just cram features forever. You must focus on the quality of the internal structures of a software system. The current realm of AI coding models are not good at this in 2025.
The most common anti-pattern here is to let someone outside the trenches of engineering define a list of what can and can’t be worked on to improve the quality of the system. Ownership of this backlog really needs to stay with the engineers who are going to maintain the product in the long run.
Joel reckons we should have a schedule. I agree in principle, but I don’t think his description works very well for the small/medium startup. What I love to see is a really well communicated organisational objective and quarterly goal set. You can spot this in a high functioning team by asking a random selection of developers (what are the six things we need to achieve in the next 2 quarters). The six things should paint a pretty obvious picture on what the business is doing, they do not need to be the exact things but you should get a clear idea of the team's alignment.
We have a lot more nuance to schedules in 2025. There is a spectrum of highly defined project management through to some very loosely coupled versions on project management. In my experience it is less important than it seems. However, my preference tends towards the process which allows me more freedom to change direction.
More important is to understand what the hell the business outcomes are, and how your product is contributing to the success in the short term.
A ‘schedule’ is not a good question to figure out if the product team is actually delivering value to the business in a way that is sustainable and going to lead to a long term stable product.
You should write tracer code. You shouldn’t spend weeks on design. Building prototypes has gotten significantly easier between 2000 → 2023. It just got insane with the release of LLM’s that can write code pretty good. The 2023 → 2025 improvement in prototyping is about the same as the 2000 → 2023 improvement. I believe we are potentially in an exponential on the ability to prototype software solutions.
Building prototypes is fun. It actually leads to building the right thing more often on average. Building the right thing is fun.
Not building prototypes is no fun. Working for a long time really hard on a well scoped project is OK I guess, but wow, it sucks when that really expensive product team delivers something that no one wants.
Coding can be collaborative (see pairing). Design is collaborative for sure! But actually when we are doing the production of software we are getting in to flow (see Mihaly Csikszentmihalyi).
The way we do this might have some subtle differences in 2025, but not as much as a lot of other factors here. We are still human and our biology changes slowly. Getting into the flow probably hasn’t changed much in 5000 years.
Maybe VR will make this better? Good noise cancelling headphones are worth a note here. Flexible working is also great, I still find an occasional evening or early morning session in the editor can be amazing for getting the job done.
Prev. “do you use the best tools?”. We are in a really insanely volatile stage of tool change in our industry right now. It is more important than ever to experiment with new tools.
What is ‘best’ is changing on a monthly basis now. You should be open to changing and exploring new tools all the time.
Now, I’m obviously alluding to AI assistants, but I think experimentation with new tools is still really important beyond the current hyper trend of large language models. Take Operating systems as an example. In my career I have gone Windows -> Linux -> Mac -> Linux -> Windows -> Linux… At each time I used these, they were the best option for the job.
Flexibility and open mindedness is important. I can remember starting my career and veterans being extremely hesitant to try new tools like Docker, don’t be like that! Explore new tools and choose what is best!
One of the trends we have seen over the last quarter century is a huge expansion of the job to be done by software engineers. More than ever, it is becoming very important to also be a ‘product engineer’. To pick up these skills you must use the software that you build.
It’s not like you need a perfect developer SME in the domain you are building software. If you find this specific type of unicorn you should totally hire them though. At least make sure that your users are close to the developers.
We must pick up some type of ‘method acting’ paradigm when we work on products, and become the person who uses the software. Understanding deeply what they are doing is key to building amazing products.
True in 2000, still true in 2025. Although we have invented a large number of variations on this in the preceding years. We have a lot more than fizzbuzz. We have leet code, system design interviews and a whole variety of coding tests that you might experience.
Release early, release often. Joel called this hallway testing. But really, you should be showing off unfinished work as early as possible. The feedback you get while you are mid feature development is 1000% more useful because you can actually immediately change the course if necessary. Another banger of a question that really has minimally changed between 2000 and 2025.
There is a ton that has not changed much at all between 2000 and 2025. We work on software that looks a lot different. Your speciality is much wider and there are more disparate parts to every product. At a high level the act of writing code looks the same, the qualities of really good engineering teams haven't changed a lot either.
The stuff that was true in 2000 as much as 2025 will be true in 2050. Take this forward to all your social media feeds and apply it to the current trends and you will be able to see through some of the obvious bullshit out there.
Even if we don’t look at lines of code in the future, a huge amount of this is still going to apply.