The Joel test

Yesterday I got asked my thoughts on the “Joel test”, as a good friend of mine got the bad news that his development team is scoring just a 7 on the Joel test. He wanted to know what it is and “Is that score a cause for concern?”

This post is going to be a little tech focussed as I am sure you are guessing, but if you are a CEO/CFO and want to know what’s going on (what you’re spending your money on in an IT development team), then you will find this post of value.

Now, I’m not a strong believer in trying to measure your development team success or their strengths by any means other than, are you happy with the product being delivered? All too often we get caught up in some form of metric for measuring just how good something is, and while we are doing that and maybe getting great “scores” we seem to lose sight that the product being delivered is actually poor. However, that being said, I think the Joel test is a good indication of your software development environment, and if that is in good working order you are at least giving them the best chances to succeed.

The Joel test is dead simple, and though I’ve read lots of opinion on it not working for Agile, I simply have to say – use a bit of common sense and apply it in the correct fashion to your preferred development methodology. I am a strong believer in agile and SCRUM, we operate that here religiously, and I would say our Joel score is at 11. Not the perfect 12, simply because I don’t always fix bugs before continuing on with new development work, I personally prefer to address bugs towards the end of a development cycle.

So here we go, the Joel test:

Do you use source control? You must be saying YES to this, simple as that. Good source control will also provide you with build services for continuous builds, see a later question.

Can you make a build in one step? Should be a YES. Builds or build scripts or continuous build services ensure your code is at least always able to build and run. When a build is broken, you have to fix that before anything else, and what’s great about a continuous build is you find these problems out sooner rather than later.

Can you make daily builds? See above I would say

Do you have a bug database? You MUST have something like this otherwise you have no hope tracking issues and fixing them. You don’t even need to be that sophisticated, though I like my UAT testers to push bug issues into the same control we use for specifying out storyboards (SCRUM).

Do you fix bugs before writing new code? This is the one I let slide. I make sure everyone is aware of them, and if they are in an area of the system that will be worked on then YES, let’s do that. However, often bugs are not in the same areas, and in such cases I prefer to keep the development velocity up and come back to those bugs at a specified date and time (typically the start of the following development SCRUM).

Do you have an up-to-date schedule? Now some will say NO to this as they use XP or something. Personally XP is hit and miss. SCRUM lets me specify out what storyboards we need to work on, and then we work on them. We don’t have an old fashion specification as such, nor an old fashion schedule, rather we have lightweight roadmaps and storyboards, because that is what SCRUM needs. So I still answer YES to this question, though we use SCRUM.

Do you have a spec? You need to have some spec, so if you answer no to this, then your development efforts will fail. SCRUM provides developers with a spec in terms of the storyboards they follow with the identified tasks. Without them, you have no hope.

Do programmers have quiet working conditions? This should be a yes, even if you are using XP. Collaboration is always ok, but the conditions will on the whole be conducive to concentration.

Do you use the best tools money can buy? We do, but I don’t think this is the end of the world if you write no to this. I personally like to push the team forward as the best tools typically help productivity.

Do you have testers? I hope you answer YES to this.

Do new candidates write code during their interview? This is harsh, but I insist on this, and what’s worse I insist it be done with just a pen and paper. I’m not looking for syntax, rather a good understanding of OOP and problem solving.

Do you do hallway usability testing? Not sure many people do this, but I do like it. I especially like expanding this out to focus groups if and when you get the chance. If you don’t have resources for this, hallway testing can be easily completed, just get some friends and family involved J

Anyway, that’s my take on the Joel test, don’t get too hung up on your score, but like Joel states, a score lower than 10 indicates serious development problems…I would probably say lower than 9 is big trouble…

The Hacker mentality in development

There is a lot to be said for hackers, many of them are, well quite simply, brilliant with computers and poses some great knowledge. I’m not approving of what they do, as I think those actions are disgraceful and show a blatant disregard for the law, privacy and peoples livelihoods. However, many companies build their software with a hacker mentality, which is “get on and do it, make it work” kind of thinking….Lots of doing, little planning….I can’t think of anything positive to be said about having a “hacker mentality” when developing a piece of software or a platform. Such a mentality is ok for building proof of concept parts of software, you simple cobble together a rough solution that shows the concept and you use it to overcome / address some technical difficulties you may see in the future. However, take that mentality and approach into the actual project and it’s only a matter of time before something comes back to bite you…

 

Facebook

Facebook is the biggest and most obvious example I can think of. The platform and social network is brilliant in many ways. However, spend much time trying to use it for business, for managing ads, campaigns etc and you get the feeling that everything really is “cobbled” together in true hacker mentality fashion. Things just don’t seem to play well or consistently and you seem hamstrung by so many restrictions which have been basically caused by not enough forward planning, rather developers just doing…You really do feel like the platform was built for its one role, and that everything else is almost stand alone trying to be bolted to the UI.

In recent weeks I have watched a digital marketing agency wrestle with Facebook in order to get it to behave how it really should. It’s not the agencies fault, far from it, once they managed to get someone from Facebook to talk too; it became apparent that most of the staff at Facebook are aware of the amount of bugs in the system and the restrictions that are in play. For me, the whole experience is at best “proof of concept” and essentially shows that there has been a real lack of forward planning. Facebook is a company though that was founded largely on “doing” rather than planning…

 

Don’t get me wrong, there are some impressive concepts with Facebook and many parts of it are implemented very well, but you cannot get away from the fact that anything outside its original core feels like its been added on as very much an afterthought and that its very “prototype” in terms of feel and implementation.

 

Technical Architecture

I’m not going to bang on about the right way to do things, rather just to say that any development project really needs certain key roles, and the biggest two are ETA (Enterprise Technical Architect) and TA (Technical Architect). These roles don’t fit in with the hacker mentality at all. If you have two people who fill these roles, and do their jobs well, you will find that as a project grows and new requirements come on board, that they can be added to the system in quite an efficient way. Tested separately and rolled out smoothly. The new additions become seamlessly part of the software and things don’t feel cobbled together and they don’t feel like prototype or beta software. Why? Well because these people plan for the unexpected, they see the bigger picture and look at what potentially one day may also be required from any given part of software. If you plan your system like that, when new requirements do come along, you can build them into the overall solution without causing any “jarring” effects within the software or for the user.

Having people who ensure you plan all components for the future keeps longer term costs down, and delivers software that can truly grow with your business. There is nothing worse than having to go back and re-engineer code because it was implemented with only that one function / requirement in mind…

 

Adaptive, SCRUM, RAD…

There will always be a better way to run your IT projects. New methods for ensuring you get code developed quickly, built to specification and future proofed. However, without having people who think ahead at an enterprise level (regarding technology, architecture etc) or people actually ensuring developers do the same, then no matter your methodology, changes further down the line won’t be easy, rather they will be quite troublesome, slow to implement and often result in a cobbled together field, ala Facebook ads management…

You simply can’t beat people who forward think…

Why IT projects fail

In my previous post I looked at “How do we ensure a BPM project succeeds”, but it got me thinking, why do many IT projects fail? I racked my brains through the very few projects I have been involved with directly that have, not failed as such, but not gone well shall we say. I also started to think back to many projects I was brought in on to help succeed, and tried to remember just why they were failing in the first place.

There are numerous reasons why projects fail, why requirements were missed, why over complex procedures are put in place when not needed etc etc. But what are the real big reasons, what do we have to really understand and monitor closely as to keep an eye on proceedings and limit the chances of failure…

Politics

Ahh internal politics. This is possible the biggest singular reason why projects fail, usually as a direct cause. So what do I mean here…Well, at the early stages of a project, you need to ensure you get the right people with the right knowledge involved, especially if you are identifying requirements. But this is where it all starts. Straight away politics takes over, and putting together a “high level” team, along with “senior users” etc all means politics kicks off. For example how often are you working in a team and realise (as a consultant) that some of the people in that team from the company just shouldn’t be there. Why are they there? In addition, you walk the floor and find key users with a lot of knowledge not involved in decision making? Their absence has meant functions are overlooked, processes missed and for what reason? Often it is internal politics that decides who is in what team…

This isn’t the end though. No, internal politics can also mean you see key personnel dropping out of projects being moved elsewhere in the company. You also find people trying to make a name for themselves using your project as a vehicle, and because of this they slow everything down, re-visit old ground and basically make everything a pain in the neck (being polite).

My favourite experience though is internal IT departments refusing to get involved because they were not consulted with at the beginning of a project. Classic….There are so many many more examples, but let’s just say, if a project is going to fail; internal Politics will have something to do with it…

Before moving on, internal politics can also lead to the wrong system, solution or vendor / consultancy being used. More often than not, internal politics determines just who the business can work with on a project, not even taking into consideration expertise, skills, price and many other common factors.

Nepotism

This follows on from politics to be honest, or could even be seen as a part of internal politics. Unfortunately nepotism can often raise its head on an IT project. In many cases (well all in my experience) this causes friction and can have a real negative impact on a project, contributing to failure ultimately (if it goes that far).

It sounds obvious, but if someone just can’t pull their weight, or doesn’t have the necessary knowledge to be involved in the project (no matter what stage) then that person, no matter who they are, shouldn’t be involved….

Building on this though, it can also lead to particular vendors, or particular firms being used when simply they shouldn’t…

Incompetence

This one is a worry, as how do you identify someone is incompetent before it is too late? Unfortunately I have worked on projects with people who just don’t have a clue. To say they are incompetent maybe an understatement. I, as a co-worker can spot this, but more often than not, manager’s spot incompetence too late. It is therefore important that managers get a feel for their team, get feedback and try to judge if anyone is being “carried” or just plainly is incompetent

Change Management, or resistance to change

This one is deadly; it seems to creep up on IT projects. The 3 reasons before can all be “nipped in the bud” with good management. In addition they show up early in an IT projects lifecycle. However, poor change management or resistance to change from staff can mean that you may have the best solution in the world, but it will ultimately fail because no one wants to change the way they work.

To minimise this, IT project managers need to get not just key staff involved early on, but as many staff members as possible. I am not suggesting they all get to put their 2cents in, but allow them to feel a part of the project, get them involved in reviews, prototypes, demonstrations, the odd focus group etc. This way ensures that when the system comes along, many users have already come to terms with this fact and the solution itself. It minimises the risk of change resistance…

Conclusion

Ultimately managers make or break a project. The reasons shown above can all be avoided with good business management, good people management and a little dash of political prowess.