House wouldn't put up with your ineptitude

Professionalism in my line of business (Software Development) is quite literally all over the map.  Putting aside issues regarding slackers (people who spend more time on social media than their code) we find the functionally inept.

Functional Ineptitude

Dealing with a normally inept person might be easy, they can’t do their job so to justify their removal from your team is a simple process of pointing out their failure to deliver.  However, the functionally inept will typically work hard and produce artifacts that satisfy the outward facing requirements set forth on the project plan.  What the Project Manager doesn’t understand is that the quality of code being produced is not robust, doesn’t stand the test of time and is so tightly coupled to the rest of the system it’s like a symbiotic parasite feeding happily unnoticed.  The problem is, once this code is noticed, it would kill the host system to remove the parasite.

Functionally Inept Developer – a Developer who by all outward facing means gets their work done; however, does so at the expense of code quality and robustness with little to no regard for the rest of the development team.

Coping Strategies

Unless you are blessed with a quality-driven Project Manager or Technical Lead worth a damn, you will be stuck with the functionally inept developer for as long as he/she can crank out code.  Given that I am a contractor, I typically step foot into companies who don’t know my track record.  In fact, a PM at one of my previous gigs told me as much after I raised concerns about a functionally inept developer.  It’s a very frustrating situation to be put in, one where you have no power to influence or change your team, yet are expected to deliver and work as a team.

So, after realizing I wielded little to no power with the “higher-ups” I decided to take matters into my own hands.

1. Break the build, get an email

What plagues software project team development more than “the broken build”?  Pretty much nothing IMHO!  It’s the fastest way to completely stop development dead in its tracks.  If you can’t build the system,  it means you can’t continue without first tracking down the source of the failure and correcting it.

The first thing you should do is setup a version control policy that reads something like this:

1. Do an update from your VCS, fix any local conflicts which might have resulted
2. Do a full compile of the code base
3. Run unit tests, ensure no failures
4. If it took you a while to resolve conflict, check once again for changes in VCS and repeat from step 1
5. Now check-in your changes with a USEFUL commit message (unlike these ones)

9 times out of 10 nobody on the team will listen to you.  So the second thing to do is setup a Continuous Integration (CI) server like TeamCity or Hudson.  If you are at Compu-Global-Hyper-Mega-Net and they don’t have CI servers, set one up yourself, even if it’s just running on your own desktop.
What a CI server will do is:

1. Checkout code from VCS
2. Compile & Run Unit Tests
3. Email the offending developer (or the team if you configure it thusly) stating the actual piece of committed code which caused a build to break

Before I had set up a CI server on a previous contract, I cringed anytime I had to update from VCS.  It was such a massive waste of my time to have to sift through the various commits and pinpoint when and how a build was broken.  Even with all my awesome CSI-esque investigation, I’d often be ignored by the guilty developer, or be told “works on my machine” as a defence.  Fast-forward to after CI was setup:  the guilty party now gets an email from an impartial build machine. That seems to prompt people to realize it was really them who broke the build, and they should do something about it.  Especially considering they’ll most likely get the email 5 minutes after their last commit.  When they get 10-20 emails a day, it becomes embarrassing for them, and they have no one else to blame but themselves.

You broke the build? Bollocks!

2. CYA with Unit Tests

Convincing a team of developers to write unit tests from the point of view of someone who’s not in charge is next to impossible.  Don’t waste your breath.  The smart ones will see your bug count and realize why it’s so low.

When you have a functionally inept developer, their tests (if they even know what one is) will suck just as badly as their code.  Instead, you need to look at Unit Tests as a defensive measure.  You are protecting your code, from theirs.  If the inept one changes the codebase in such a way as to break your functionality they’ll find out right away because a test which ran successfully before their changes ceases to afterward.
Sure the functionally inept will tell you “it’s your test that is broken, not mine”, however you have to make them understand that it was their changes which broke existing functionality and they better have a pretty good reason for doing so.

3. Followup Code Reviews

I’m not even going to go on about code reviews and how important they are.  What people seldom understand is the importance of a followup review.  Case in point, I was at a gig where a functionally inept developer was up for code review.  Of the various problems noted, two were outrageously inept.  The first was a 650 line long method (Cyclomatic Complexity of 14+ if memory serves).  The second was that the aforementioned  method was not thread safe.  This means, if two threads called the method at the same time, you could never guarantee a proper response.  It would be like a database which didn’t support transactions, you never know if your application was prone to dirty reads. Comp/Sci 101.


The developer in question was more mad at me than embarrassed.  He saw no problem with his 650 line long method and didn’t know what thread-safe meant or why it was important.  He was a “senior developer“.  I proceeded to kindly explain to him that we were writing web services and thus multiple requests could be calling the same function at the same time.  I spelled out a pretty simple solution to fix the code, but alas it fell on deaf ears.
For a few weeks after that review I kept my eye on commits by this developer, none of which pertained to fixing either of the aforementioned problems.  I proposed a followup review and the tech-lead stated there was no time in the plan for one.  That code went to production as far as I know.

4. Demand from Others what you Expect from Yourself

You are a professional, you shouldn’t be ashamed of demanding as much from others.  You’ll notice the pictures I chose for this article are of the fictional character Dr. Gregory House and the very real character Chef Gordon Ramsay.  I did so because Dr. House will call you on your bull if you are inept or cut corners and Chef Ramsay expects nothing but the best possible job you can do.  A lot of people think Ramsay is “an a-hole”.  I just think he has a high standard that he strives for himself, and is very disappointed when others fall short of that mark.


The truth is, Software Developers are not held to the same standards as Professional Engineers.  So stop calling yourself a Software Engineer.  Anytime I hear that designation it reminds me of this Denis Leary skit.  The fact of the matter is every company allows their developers to operate in different ways, most of which are dysfunctional.  I don’t know why we’ve gotten away with this for so long, but it’s the reality of our profession.


So in closing, strive to do the best you can, educate those willing to learn and keep inept developers (functional or otherwise) at as far a distance from yourself as you can.  The code-grenades they produce are theirs to jump on, don’t become collateral damage when the pin is pulled.