Because the road to hell is paved with good intentions.
***This is satire***
Nov. 1: Excited sales guy brings in major project. Development team estimates six months until completion.
Nov. 4: Sales guy shares that the client signed the contract! Oh, and per the agreement, the dev team has two months to deliver the project.
Nov. 5: Assemble an all-star team… it might be possible to finish this time if we can get our best developers on it! Except, our star senior dev leaves for his month-long honeymoon next week and our solid junior just quit after realizing we’ve been drastically underpaying him.
Nov. 7: Team ramps up while waiting for design team to deliver promised files.
Oct. 18: Waiting.
Oct. 19: Waiting.
Oct. 21: Waiting.
Oct. 25: Still waiting.
Oct. 31: Finally got the design files! Let’s get to work.
Oct. 31, continued: While fielding a question about site navigation, a team member notices that the designs contain hamburgers and recalls that the contract specifically said not to use hamburgers.
Nov. 1: Spend a day figuring out a workaround before realizing we’re screwed. Files go back to design team for updates.
Nov. 7-8: Designs finalized. Spend two days arguing which framework to build it in.
Nov. 9: Settle on a framework — a fresh one recommended by the new hire. Build.
Nov. 13: Realize said framework won’t support the product. Start over from scratch.
Nov. 14: Project is due in 1.5 months. Make the decision to tell the client that we’ll need to scale back functionality to make the deadline. Hold six meetings to figure out how to make it sound like the client’s fault.
Nov. 16: Sales team returns with big news… the client will pay an extra $20k if we can deliver on time with all of the said features. Dev team says it’s not possible. Sales guy says that’s too bad because they already signed the new contract. Sales guy enjoys extra commission. Developers enjoy the expectation of more unpaid overtime.
Nov. 17-29: Build like crazy! Social lives dwindle to occasional messages from family wondering what happened to plans to visit for Thanksgiving.
Nov. 30: New hire tasked with building a single feature can’t get it to work. Admits he didn’t learn this level of complexity when he was at a coding bootcamp two months ago.
Dec. 1: Client demo goes down in flames. Client is somewhere between pissed and furious.
Dec. 2-5: Team lead spends entire days trying to fix coding school grad’s feature before deciding to rebuild it in a night. It now works perfectly.
Dec. 6: Developers realize they’ll have to work through the holidays. Sales guy shares that he’s booked a tropical vacation and will be unreachable until after Jan. 2.
Dec. 7-20: Developers build as fast as they can to pull together a barely functional product. QA team immediately calls them on said barely functional product.
Dec. 22: Bug fixes.
Dec. 23: Bug fixes.
Dec. 24: Bug fixes.
Dec. 25: Bug fixes. Even the Jewish developers think this is fucked up.
Dec. 26-30: Bug fixes. Developers start thinking about bugs in their sleep.
Jan. 1: Team delivers some version of a functional product, anxious as they await client feedback.
Jan. 7: Client emails to thank the team for their work, adding that her company opted to halt the project back in mid-December. Feels a slight pang of guilt for making the dev team work through the holidays before going back to drinking a $15 Juice Press smoothie while shoe shopping at Nordstrom.com.
Jan. 8: Project post-mortem. Long-winded speech from CEO about supporting the company, working together, company culture, relying on one another, how great the company is, pushing expectations, and, of course, the incredibly amazing company. Speech is followed by an apology about the lack of holiday bonuses.
Jan. 9: Sales guy announces his promotion.
Software development is an extremely complex process. Particularly in cases where the client is nontechnical, a software team may struggle to try to explain why things haven’t gone as planned. In turn, the client may be confused as to why a project can’t be completed according to schedule, even in spite of the developing team’s best efforts.
I wrote this as a guest post on behalf of the Waydev team because they are trying to solve a problem that affects nearly every nontechnical person who works with a development team on a regular basis. The tool, which offers data-driven insight into software development velocity, not only holds software teams accountable for their work but also allows the nontechnical client to offer direction on the fly (rather than waiting for a report from the project manager).