Best practices

The perfect case study.

There is a great article in today’s New York Times outlining the factors that led up to the failure of the website.  The project, doomed from the very early stages, is a textbook example of how not to manage a project and should be taught in every university’s Computer Science program.

If only they had followed my credo.

My credo

I was recently asked to describe my development credo.  At first, the question seemed odd to me.  My “credo”?  When I asked for clarification, my interviewer said, “Yes, those core beliefs or concepts that you apply to every project despite the actual methodologies or technologies used.”    After some thought, I realized it wasn’t really a bad question after all.   As technologists, our environment and tools we choose to interact with that environment are constantly changing and evolving.  Yet, there are touchstones that we carry with us from project to project, formed from past experience that we use to gauge and ensure a project’s success.    So here are some of mine:

1. Think small.   Over the years I’ve seen far too many important and well-funded projects fail because the team was too focused on analyzing, documenting and designing every detail up front.  Wanting to make a big splash by delivering at scale, they thought too big.  In the end, they ended up just being all wet and after many months of work all they had to show for their efforts were a stack of diagrams and a long list of requirements.  Meanwhile, the landscape had changed and those core business needs that the development team had spent so many months analyzing were no longer relevant.  I take the opposite approach because I strongly believe it is better to get something small deployed quickly, know that it won’t be perfect, solicit feedback, be prepared to change everything, and then iterate, iterate, iterate.  It’s the only way to ensure that what you are building remains relevant and will meet the needs of your users.

2. Don’t fall in love.  I’ve seen projects fail simply because the client, architect, or development lead was a fanboy of some new technology that, although great for some things, was the wrong match for that project.  No matter how great you think an idea, a technology, a thousand lines of code is, you have to be emotionally detached enough to recognize that and throw it to the curb if it isn’t meeting your needs.  The hardest part of my job isn’t writing code, it is deleting it.  Don’t get smitten.

3. Be lazy.   When I was a junior-level developer I spent time working on projects where success was measure by how many lines of code were written per day.  Being young and lazy, I never scored very high on those metrics.   But the great thing about laziness is that it demands that you find shortcuts.  Why waste time writing thousands of lines of boilerplate code if you can more quickly automate the process and take a long lunch?  Today, I encourage this behavior in my developers because it is through these time-saving discoveries that the entire team becomes more productive.

4.  Steal.  I currently work for a large multiunit, multinational corporation.  The way it operates you’d think the various units were warring countries.  One unit in particular has adopted a “not invented here” attitude when it comes to new technology or even sharing code.   Their projects are always late and typically suffer from a lack of innovation.   Again, I take a different approach.  I know that my chances of being the first person who needed to solve my problem are pretty low and it’s likely that there is already a library, framework or snippet of code out there that will solve most of my problem for me.  I can’t afford to waste time reinventing, I’d rather be innovating.  So, I encourage my team to adapt and reuse whenever possible…but abide by the license.

5. Be inefficient.  I know developers who get a perverse satisfaction out of squeezing as much function into a single line of code as possible.  The problem with this approach is that it makes their code nearly impossible to read for anyone else.  Modern compilers are going to do a pretty efficient job optimizing your code so there isn’t a need to be so terse.  You should instead adopt a coding style that allows others on your team to quickly discern what you wrote.  If it takes 2 lines of code to make your intent crystal clearer, write two lines of code.  And comment.

6.  Say no.  The first project I was worked on after college was a disaster.  It was a year behind schedule with no end in sight because they adopted a waterfall methodology and their client and corporate management keep changing the requirements.  The leadership on the development team would not say NO to even the most inane requests.  It’s a simple word, two-letters, easy to pronounce yet it rarely comes out to the mouths of architects and project managers.  I think it is far more important, especially in the early stages of a project, to clearly define a very limited scope and then deliver that on time.   No one likes to fail and a small victory is still a victory.  Don’t commit to the impossible.  Say No.