The video at the end of this post (and images throughout) is a great visual example of one of the most common failures in Customer’s  expectations in relation to project delivery.  They want the 1st Spiderman quality but it must be delivered in the same time as the 10 second attempt.  And a project will always fail in that pattern.  The project and creator could be just about anything and it fits… Whether you are a home builder, manufacture, artist, grounds maintenance, designer, developer, engineer, etc…

For me as an Architect, Software Engineer, Software Developer… this is what we struggle with all the time. Regardless of Water Fall or Agile. Regardless of the size of the software project or enhancement. The company, the client, the project manager either have unrealistic expectations on a project timeline or someone higher up messed up somewhere or promised the project and deliverable without checking with the team first, to see what projects they are working on or already promised for.

I think this is a “Failure to Communicate” from all parties involved. Let me focus on this from the view of the developer. The developer can easily fall victim to thinking he can get a given task done in a short time frame, but he may be unaware that the requirements are wrong or incomplete, the sagittate code he needs to work in, the defects that may already exist that will be found in testing but not at all related to the changes he will make, the bad data that will cause delays in his own unit testing, the poorly designed database with no relational keys, etc… Or there is the time when the developer is interrupted and asked about a feature, or enhancement, “how much time do you think you need”, a quick thought is given to the feature or project and a time (guess) is given… The project manager takes the time and moves forward, maybe reports this up the management chain… Commitments and promises are made… Sometime later requirements are made and given to another developer who reviews the requirement and the estimate is 2 to 3 times as much, but commitments and promises were made.

As the developer we need to constantly update project managers and management of the environments, conditions and situations we find ourselves in and the implications of proceeding with the project as it is (and add additional work to technical debt), or fix it as you go and project takes longer (often unknown length of time). We need to be cautious when tossing out wild guesses, in fact, stop doing that. Take the time, do the research, and come up with a realistic estimate. If management can’t wait, then inflate your SWAG (scientific wild ass guess) by 4 time or 6 times.

What management and developers often don’t think of there is more work and time that goes into a software development task than just the actual coding. There is… review of the requirements (ask questions, and get even more details to those requirements that are lacking the details [repeat]), research existing code base (some or a lot of existing code may need to be refactored), schema and data, UI design (review, change [repeat] until approval), schema design changes (and data, with review and approval process), the actual work (code, scripts, graphics, database) along with unit testing (by the developer or coded unit tests), then official QA testing and approval (after any bug fixes). Even simple changes and features all that I just described can add up to a lot…

BUT when done right in whatever time it takes, the client (business, management, whatever) gets the finished 10 minute Spiderman, but when rushed and pressured into unrealistic timeframes, the client ends up with the 1minute Spiderman or worse the 10 second Spiderman. OH… yes, the client will not be happy with the 10 second Spiderman, but the developer won’t be happier either because he knows the mess that was made in that rush to make a timeline produced a mess of spaghetti code, bad design, bad schema, code that is not reusable or extensible and will need to be refactored and cleaned up some day.

I had a brief discussion regarding this topic with a friend developer of mine… here are some good quotes:

• • • • • One of my favorite phrases is “If you don’t have time to do it right, when are you going to have time to do it over.”
        • The reality is we seldom get to go back and fix this or that or clean up our code. So, the messy code we wrote to deliver on time stays for months and years.
        • So, you keep increasing your technical debt more and more as you go. Pretty soon you’re up to your eyeballs in technical debt and the only way to fix it is to file technical bankruptcy and wipe the slate clean and start over from scratch.

Well… I went on long enough about this. Hopefully, you get my point, understand what I’m getting at and maybe even had a laugh with “yeah, I’ve been there”, or “Yeah, that’s the way it is here”.