Most of us have had experience working on projects where tight deadlines result in corners being cut and quality being sacrificed in the attempt to push an application into production. But I can't help but wonder what would a typical project in a Bizarro World look like?

The Typical World

Examples of sacrifices that I've often see on such projects may include:

• Reducing automated test coverage in the belief that writing less tests allow developers to write more functionality.
  
  
• Using legacy software and frameworks with the justification that upgrading would take too much time learning new tools/frameworks and re-working the codebase
  
  
• Not fixing broken builds so that they stay red for days on end
  
  
• Copying and pasting code willy-nilly
  
  
• Letting tech debt build up to the point where their very existence is forgotten
  
  
• Not taking the time to "think" or read documentation and instead hacking shit together
  
  
• Where delivery dates overcome everything else
  
  

A Bizarro World Project

However, consider for a moment what a project that lies on the opposite end of this spectrum might be like. A project that might only exist in a Bizarro World. One where:

• tests are written religiously and to strict 100% coverage, sometimes only for the sake of attaining that 100% coverage goal. Where lots of mocks prove that the code interacts with each other the way the tests expect, but not that a piece of functionality actually works as a whole. Developers will invest huge amounts of time unquestioningly writing and maintaining these "white box" tests that, at the end of the day, do nothing more than "run fast" and make coverage levels look good
  
  
• only the newest and most bleeding edge tools/frameworks are utilized at the expense of stability and progress in deliverables. Where large chunks of developers time are dedicated to integrating and re-writing chunks of the codebase to accomodate the latest-and-greatest technologies. All of which occurs without any proper analysis on the true impact of such tools and frameworks
  
  
• team members are soo afraid of designing something "badly" that any concerns they raise allows them to immediately take time out to attempt to "clean up" the code. Team members are also soo afraid of saying "no" to a proposal to refactor in the fear that they'll be seen as not being concerned about quality. Questioning whether a refactor should go ahead is not necessarily an indication of a lack of concern of quality, but could instead be seen as an intent of staying focused on delivering business value. The interesting thing here is that every developer thinks they can write the code better than what is already there.... where does it end???
  
  
• the benefits of pair programming are completely unquestioned (yet have no actual metrics) and large chunks of time is taken up between a pair discussing possible solutions to a coding problem. Worse is where your opinions differ but you're trying to be polite enough not to completely dismiss your pairs ideas whilst simultaneously trying to push your solution. Frustratingly, this process can sometimes take 10 minutes for each line of code ...
  
  
• tools, frameworks and designs that are overkill for the job are used out of the teams interest in exploring new ways of doing the same thing and without proper impact analysis. The result is that more time is expended than originally thought because those new technologies have unexpected consequences. Also, large chunks of the project may need to be re-worked
  
  
• the team has no visibility of deadlines and are told to "slow down", thus giving individual developers the impression that they should question every line of code (resulting in the fact that they do) and refactor anything (also resulting in the fact that they do). Basically, the developers by this stage would have lost focus on the projects objectives and are completely consumed by a misguided sense of ONLY trying doing things "right" (which in itself is very very subjective)
  
  

I'm not sure what life in such a Bizarro World project would be like. Probably a project where very little gets done but alot of talking takes place. Needless to say, a balance needs to be kept between the "Typical World" and the Bizarro World.

A good penalty is one that hits the back of the net

The phrase in that heading just above is a popular one in soccer. It really doesn't matter if the keeper touches the ball on the way in, or if the ball hit both posts before crossing the line, or if it was smashed into the top corner at a hundred miles an hour... all that matters is whether the goal was scored. On that note I'll finish this post of with a question. Could it be that a successful project is simply one that gets delivered to the satisfaction of the business?