Introduction

The original Joel Test is a work of genius – it allowed you to assess the quality of your development teams in under 5 minutes.  By answering the yes/no questions, it steered you into thinking through each of the points and understand weak points in your process.

It was written in August 2000 (that’s before Windows XP was even released) and is still very relevant today, which suggests that a lot of IT teams are still making the same mistakes they were making 18 years ago.

I’ve heard one developer sum up the Joel Test perfectly when he said, “the beauty of the Joel Test is its simplicity vs its effectiveness”.

Just as the original did, these tests deliberately cover the basics. I have intentionally not included tests such as “are you agile?” or “do you do DevOps?” as a lot of people misunderstand these concepts and unfortunately they sometimes get thrown around as management buzz-words.

Just for the record, I have worked mainly as a data warehouse & BI developer for financial services firms in London, within IT teams ranging from 2 people to 100s; if I had spent my career working as a web developer for Facebook or Amazon then I’m sure my tests would be quite different.

Remember, Yes = 1 point.  No = 0 points.

01 – Does your team have a goal… and do all your team members know what it is?

Do your team members also know what their individual goals are and those of the company?

This is universal and applies to any team/individual and is not really about having goals – which all companies will have – it’s about whether or not they are being communicated down the layers and making sure everyone is striving for the same success.

Benefits of having clearly understood goals

• Much more cohesion between teams when people pull in the same direction.
• Goal-relevant activities take up a lot more of the overall effort than goal-irrelevant activities.
• Managers cannot motivate teams by assigning out a series of seemingly unconnected tasks.

02 – Do you (actually) use source-control?

**This mainly applies to database code and not application code.

Most of the companies I’ve worked for have usually had at least one source-control system up and running.  Whether the developers actually used it was another story.

Just having a source-control product installed was enough for a lot of managers – it gave them that false sense of security and is another box ticked.  Often it was only used by the more competent developers when they were given the chance to work independently; these projects were naturally of a far higher quality and had a much higher success rate than the rest.

Source-control is absolutely key if you have more than one developer work on the same solution or you want to start implementing DevOps practices.

Grant Fritchey once summed it up perfectly when he said, 

“there are only ever two known states; Production and Source-Control”

Other environments such as Development, Integration, Test, UAT, QA or Pre-Prod are all transient combinations of Production (baseline) and Source-Control (changes).

Whenever you compare two environments, at least one of them will be production or source-control.

If managing your environments and preparing releases has become total chaos then it’s probably time for a reset and to start again with source control as your first step.

03 – Can you provision a new environment in less than a couple of days?

Virtual machines can be spun up in minutes.  Installing software, copying files and restoring databases isn’t hard.  So why can development teams wait for weeks and months for fresh environments when the cost to productivity is so high?

It comes down to either a lack of understanding, a lack of trust or differing goals across teams.  In any case its unnecessary and it’s a red flag.

04 – Do the people who perform the deployments understand the changes they are making?

Normal practice at the companies I’ve worked at has been that DBAs do releases.  Usually, the first awareness they have of the change is around 5-minutes before they press the execute button on the scripts.  Who is this helping?

Development and releases aren’t just some formulaic activity where you can manage all risk by filling in paperwork and then blindly click go at the end of it.  All parties involved (developers, testers, releasers etc.) should be aware of the change and work collaboratively on it, as opposed to a siloed, assembly line approach.  This is especially true when releases go wrong.

DevOps provides answers to this problem but you don’t need anything more complicated than communication and bringing teams closer together.

05 – Do your developers follow the same process as each other?

It really doesn’t matter what your team process is, if each developer defines his own path to production then you are going to have a stress-inducing time trying to know what is going on and trying to manage it.

You don’t necessarily need Continuous Integration or automated deployments – as long as you have one process that all developers adhere to then you have a good chance of success.

06 – Do you have repeatable tests?

The world of testing with regards to application development is very different to that of BI/ Data Warehouse development; the following applies more to the latter.

If your PMs are still managing projects using the traditional waterfall approach then it is likely that the testing for your brand new data warehouse will be squeezed into a couple of days at the end of the project plan, usually with expectations that it is nothing more than a ratification step and that you won’t have any problems – an expectation that will quickly be blown out of the water.

The point of testing is to improve the quality of the product.  You should be testing early and often and using repeatable tests to give you confidence every time you make a change.  Testing takes skill and an understanding of the solution being tested, it cannot be done at the end of process in isolation (see point 04 above).

07 – Do you perform end-to-end testing?

“End-to-end Testing is the type of software testing used to validate different integrated components of an application by testing the flow from start to end” – From Wikipedia

End-to-end testing makes perfect sense.  The only reason people don’t do it is because the architecture of their production systems is too complicated to recreate and safely configure as a test environment.

Struggling to put together a complete test environment to help you do realistic tests is a symptom of a much more fundamental problem and it is worth considering some refactoring work to pay down your technical debt.

08 – Do you perform deployments without fear?

I’ve borrowed this question from Gene Kim and will leave you to consider your own situations.  Gene’s book The Phoenix Project is amazing for anyone working within IT and reading it will make your life so much easier.

09 – Are your developers free from distractions?

Joel’s original test asked “Do your programmers have quiet working conditions?”. 

I completely agree with Joel about his thoughts on this and about developers having to get in the zone.

I would, however, extend his original question to include all office distractions, such as

• meetings to attend with no agenda?
• automated system emails being sent out throughout the day?
• emails being sent to developers that have no relevance to them?
• constant Slack or Skype for Business alerts popping up?
• lots of paperwork to fill in each day?
• people continually asking for updates

Often a noisy, open-plan office is out of your control – at which point headphones are an essential piece of equipment.  At one company I had a manager who banned headphones on the basis that it would ‘make the team more approachable’ – a miscalculation in my opinion that demonstrated he didn’t understand the nature of the work.

10 – Are your desktops, servers and applications mostly standardised?

Whilst I don’t expect perfection, having your environments running the same operating system, being on the same domain and running the same version of the software you are using is essential in preventing time wasted through troubleshooting perfectly good code.

Again, whilst developers should have full access to their machines to install and configure them as required, there should be a ‘developer build’ or at least a central software repository where standardised software can be installed.

I’ve had situations where 3 new servers with the same version of SQL Server have been delivered by the same individual (on the same day!) but have been setup with different naming conventions, seemingly random service accounts, bizarrely different drive setups and even different collations… all of this when you are expecting a fresh start and solid foundation.

Another rule of thumb for data warehousing; if databases co-exist in your production environment, then they should co-exist in your other environments.

The only answer to this is a bit of care but its worth reading my post on broken window theory to understand more.

11 – Do developers make up the majority of your development team?

In recent years, I have noticed there to be a proliferation of nebulous new roles that all involve telling a single development resource what to do, how to do it and then demanding daily updates.

Job titles play a major part in defining expectations of what people feel they should be doing and should be considered carefully.

I have been on projects where I was the only developer but we had 3 project managers.

Of course I don’t think you should only have developers; good business analysts who have a deep understanding of your company, the industry, the systems and the data are absolutely crucial.  Good project managers are rarer but also contribute greatly. 

Each individual should be judged on their own merit but with a lot of companies employing Enterprise, Technical and Solution Architects, Project Managers, Agile Coaches and Scrum Masters – we should endeavor to ensure that the balance of each team is right.

The agile manifesto also recognises the tendency to try and over-manage development work when it says

“Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.” – Agile Principle 5

12 – Is the decommissioning of legacy solutions part of your strategy?

“Simplicity–the art of maximizing the amount of work not done–is essential.” – Agile Principle 10

Decommissioning legacy solutions (applications, databases, reports, servers…anything at all) reduces risk and complexity; it makes your company nimble and is the most impactful thing you can do when trying to achieve data governance; “if it doesn’t exist, it can’t go wrong”. 

So we have to ask, why don’t teams do it?  The reason is two-fold; firstly it’s easier, more exciting and better for your CV to work on new solutions.  Secondly, individuals who think long-term and in the company’s best interests often don’t get the credit owed to them and so stop bothering.

The solution to this is to explicitly have foundational work, such as the decommissioning of legacy solutions, as a key part of your IT strategy and for its value to be understood at the executive level.  If it’s not visible then unfortunately it isn’t going to happen on its own.

13 – Do you do execute the basics faultlessly before attempting more complex work?

Are you building a data-lake even though your users can’t run basic operational reports?

Are you looking at Robotic Process Automation even though the printers don’t work and the meeting room PCs won’t turn on? 

To me, these are warning signs that you have the wrong leadership in place and that they are banking on revolutionary solutions when an evolutionary approach is much more achievable and will have a bigger impact.

I would recommend reading about ‘marginal gains’ and ‘theory of constraints’ to understand more.

14 – Can you deploy trivial changes to production quickly and easily?

A key concept of Lean is small batch sizes.  A key concept of DevOps is delivering value from development to production faster.

Certain trivial changes, such as adding comments or tidying up names of objects, may not add customer value but are examples of simple, low-risk changes you can make and then never worry about them again.

Writing software can be likened to writing an essay – you will churn out lots of content really quickly and then make thousands of corrections, clean-ups, alterations and refactors.  Even considering this blog-post, if I had to batch up my alterations and wait a week every time I wanted them applied to the document then you can understand how difficult it would be.

Quick-Fire Bonus Round

And here are a few extra tests that didn’t make the cut but are worth including with no further explanation provided…