Six Weeks Steve

Gary was sitting at the local café, enjoying his morning coffee and a muffin. He was taking a well-deserved break following a release of his new client’s software the day before when he spotted his old manager Steve walking toward him.

"Gary!" Steve shouted. "I was just about to give you a call!"

Gary, still half-chewing on his muffin, paused and considered his response. Steve was his former boss at his previous company, and Gary still had nightmares about it. "Oh, Hi Steve," he sighed dejectedly.

Steve continued, "Yea, I've got this new project! Right up your alley. I venture it’ll take six weeks."

And it was those two words, "six weeks", that caused Gary to cringe. Gary had worked for Steve five years earlier. The company provided a variety of customized software solutions for businesses and employed a team of developers and consultants to do so. The pay was right, the commute was great, and the work sounded amazing. The only problem was the management, or more specifically Steve.

Six Week Database

Gary’s first project with the team was to create an application that maintained a database of every herb and mineral sold in America, linked to any and all diseases they might treat, while simultaneously integrating with an existing, proprietary solution. Gary’s responsibility was to help draft a short proposal for the client and then lead the team in developing the application. Gary spent hours planning out each phase of the project, calculated the number of man hours required, and determined the earliest possible release date for the project. With his staff of four developers, Gary estimated it would take eight months to develop from start to finish. He sent his proposal to Steve who, after some modifications, passed it along to the client for review.

A few days later Gary was holding a signed letter from the client agreeing to the proposal. Gary reviewed the document and discovered everything was exactly as he had written it, except for the time estimate. Steve had altered Gary’s letter to indicate that it would take six weeks to finish the project.

Gary ran to Steve’s office, "Steve, how could you promise this will be done in six weeks?"

"Really Gary, your estimate was ridiculous. I’ve been in this business a lot longer and am positive we can do it faster. In fact, one thing that would speed up the process is if you stopped using open source projects and started developing in-house libraries we could use."

Gary had quickly discovered Steve despised open source tools. Steve believed developers working on an ‘aggressive’ project deadlines would work faster if, say, they developed their own Object Relational Mapping (ORM) tool, rather than use a publically available one. He also believed in implementing their own custom web service library instead of using a standard one that was available.

After three months of work, well past the 6-week deadline, Gary was informed that two of four developers on the project would be reassigned, leaving him and two junior developers to finish the entire contract. Somehow, the sales team was able to keep the client from walking away with the promise of future updates, support, and feature after unimplemented feature. Gary suspected that even the client knew six weeks was impossible and never expected it to be completed so quickly.

A Long Six Weeks

Fast forward to eight months later, and the application was finally launched. Gary was happy, relieved in fact, to be done with this project that had taken almost a full year to complete. Steve called Gary into his office to discuss a new project, this one involving a high-speed assembly-line car part photo scanner. The goal was to build the software the device would interface with, deploy it around the country, and organize the results into an online registry system. Of course, Gary would have to complete all of this without sending any developers or technicians to visit an actual factory where the software would be used. After submitting his initial proposal, Gary came to Steve's office for a meeting.

"Gary, good you’re here. I see you estimated five months for this project. I really think it could be done in 6 weeks. This time, take my advice and implement your own libraries to get the work done. It is way easier than it looks."

Gary argued with Steve about the timeline but soon discovered he was fighting a losing battle. Steve had made his decision that the project would take six weeks and no reasonable argument was going to convince him otherwise. After two months of working long hours and on weekends, Gary was called into Steve’s office and was greeted by a room full of gentlemen in very expensive suits.

"Gary," Steve began. "Why are you behind schedule on the photo scanning project? I’ve explained to the upper management here that we agreed it could be done in six weeks, and yet here we are, eight weeks later, and nothing to show the client."

Gary did not know what to say. He considered finger pointing or claiming he had never agreed to six weeks, but somehow he knew that would not help at this moment. Steve was pretty friendly with the rest of the upper management and had already laid the groundwork for why this was all Gary’s fault. Gary received a firm chewing out by five highly-paid executives and returned to his desk.

Six Two Week's Notice

A few weeks later, Steve asked Gary for a new estimate, this one on a "medical doctor program" that could diagnose any disease given any set of symptoms. It was Steve’s pet project to save the company. Having some background in machine learning, Gary informed Steve such applications had been developed in the past with limited success and the cost and resources required were massive, not to mention the doctors they would have to hire to analyze and help build the system. Steve also used this meeting to announce his wife was pregnant, and Gary wondered if she would be due in six weeks.

After the usual deliberation theater, Steve handed Gary a proposal which guaranteed the project would be done in six weeks. Luckily, though, this time Gary handed his boss back a different kind of proposal, one that said he was leaving the company and wishing Steve the best of luck. Gary had received an offer from another consulting company and was moving on to greener pastures. Gary later learned the medical scanning project was cancelled by management after three months.

A New Opportunity

Years later, sitting in the café, Steve was again asking Gary to participate on a project that would, as usual, take six weeks. Out of morbid curiosity, Gary listened to Steve’s pitch.

"The project is to build an online reservation system. We’ve spent months on the design. I estimate it’ll take three weeks to build the ORM layer, the database, and the business logic. Probably, three more weeks for the UI. Oh, and two weeks for testing."

Gary was shocked; Steve had amended his usual six week development cycle to include two weeks for testing. He could only wonder what enterprise magazine article had prompted this change.

Steve continued, "We don’t even need you full-time. I figure you and another part-time developer could have this done in no time at all."

Gary responded, "So, the GUI mockups took several months to develop and you expect the whole thing could be programmed from scratch by two part-time developers in six weeks?"

"Yep," said Steve. "And it’ll be faster this time because you’ll develop your own database driver to interact with the system!"

Gary finished his breakfast, thanked Steve for the conversation, and started to head for the door. On his way out, he turned to Steve and said, "Look, the project sounds great, but I’m just not available right now. Why don’t you check with me after the application launches version 1.0, say in six weeks, and I’ll help build out additional features for the client." Nearly ten months later, Gary’s phone rang and the caller ID indicated it was Steve. Gary decided to let the call go to voice mail. "Perhaps," he thought, "I'll respond in six weeks."

[Advertisement]
BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!

Featured Comments

How could anyone think that writing your own version of a library would take LESS TIME? Maybe I haven't worked in industry enough...

Oh, that's easy! When you write your own library, you know exactly how it works and you can even write in your own custom hacks so that the code on top of it will be more efficient. When the library is more efficient then your code will be more efficient and you can get things done faster.
You also don't have to spend any precious time reading documentation or setting up and configuring the library to make sure that it will work in the context of the current project.

Of course you can't trust open source anyway - it is constantly changing, so we would need to be constantly updating our software around the library, and when the source code is open then any one can examine it and find holes to exploit and we don't want that.

Besides, who reuses anything these days when it is so easy to just write things from scratch. On that matter, you are going to be writing your own custom programming language designed around this project, which of course will require its own compiler (which can be used to optimize things saving even more time), as well as a new IDE built around the new language and compiler. We will also be using our own custom protocols for data transmission, and we need our own custom database engine to optimize our custom schema and data processing needs.

With all of the time that I estimate that we are saving by writing custom, optimized versions of everything (and about 100 more developers), we should easily be able to trim the whole project down to six weeks!