I’ve been working in this industry a long time.  I’ve been on projects that were truly a joy to develop for, and I’ve been on projects that were so painful to work with that I found myself wondering if I’d chosen the wrong career.  In hindsight, there are some characteristics that were shared by all of the “good” projects I’ve worked on.  In this post, I’ll describe some of those characteristics.

Note that I’m going to use the phrase “good project” subjectively in this post.  It simply refers to any project that I enjoyed working on. 

The Path of Least Resistance

I think all projects develop a “path of least resistance” to getting things done; the path where the developer encounters the least friction while working.  By friction, I mean anything that slows the developer down or causes frustration, including difficulty in testing (one of my personal peeves), difficulty in divining where to make changes, fear of changes cascading in unexpected ways, bureaucratic overhead, etc.  In a good project, the path of least resistance will help lead the developer towards a solid (SOLID?) design, one that is easy to understand, easy to test, and easy to maintain.  The developer won’t have to burden themselves with the details of infrastructure concerns; the project will provide the core concepts so that developers can concentrate just on the logic necessary to implement a feature. 

In short: the developer encounters minimal frustration en route to creating code they can be proud of.

Testing is Easy

This is somewhat related to the previous point, but writing unit tests (or integration tests) is easy in a good project.  Things are loosely-coupled, existing code adheres (more or less) to the SOLID principles, so creating test cases is pain-free, or at least very close to it.  Conversely, on a bad project, creating tests is difficult, and developers will encounter such tremendous pain when attempting to employ Test Driven Development principles that they may stop creating tests altogether. 

Developing is Fun

This last point is definitely the most subjective, and it’s the hardest to quantify.  On a good project, the developers will actually find the act of creating code to be a fun, rewarding exercise as opposed to a frustrating, painful experience.  I’ve worked on projects where I woke up in the morning and looked forward to opening up my IDE.  Sadly, I’ve also worked on my share of projects where I’ve dreaded every new feature because I knew how much pain and suffering I was about to endure. 

So What?

So why does any of this matter?  First, a happy developer is a productive developer.  If a developer enjoys what he’s working on, he’s far more likely to stay focused on it.  He’s also more likely to stay put and help bring in new developers.  Conversely, if a developer is frustrated with what he’s working on or doesn’t see a safe way to proceed forward, he’s likely to become distracted easily and will produce inferior results.  He’s far less likely to hang around or encourage others to come work on the project. 

Second, good design, one of the characteristics of a good project, means your developers will be able to implement new features and fix bugs more quickly, not just because they’re enjoying themselves, but because the project’s design makes it easy to accommodate changes. 

A “good project” isn’t something that just happens.  It takes a lot of work to get there, and probably just as much work to stay there, but I have found that it’s well-worth the effort.