Sustainable Pace (Tortoise and the Hare style)
This isn’t something new I just made up, and it applies almost everywhere, but for some reason people all too often think it doesn’t apply it to software development. Let’s look at 3 different projects, one using a paradigm of sustainable pace (SP), and one using a naive approach we will call frantic pace (FP), and one using an uber-conservative approach we will call granny pace (GP).
Beginning of Project:
SP: Make a realistic project plan with estimates based on past performance, or padded by a reasonable factor if this is our first go round. We base it off of current resources, or if we are planning on adding new resources for this project, we count them as less than 75% based on their skill/experience level for a ramp up period. If this estimate comes out to longer than the client/business expects, we eliminate features or potentially add a few more resources if the project type and funding exists accordingly. Come up with a date of X.
FP: Make a project plan expecting 100% output or 100%+ (nights, weekends) of all resources, including expected future hires. Shorten testing time and assume somehow this pace will produce fewer bugs “because it just has to, we have to meet the deadline no matter what”. Eliminate little to no features because this project needs to be the biggest and best immediately. Come up with a date of X/2.
GP: Make a project plan that adds an arbitrary and large factor of time to every step. Plan a waterfall approach that eliminates all shorter iterations of requirements -> coding -> testing -> user acceptance. Assume no resource can be productive more than 75% of the time. Come up with a date of 2X.
Middle of Project:
SP: Things are going fairly smoothly. A few dates on tasks or milestones have been missed, but others have come ahead of schedule and you are overall on track. Developers have frequent deliverables so they are not procrastinating, but the timelines are reasonable so they are developing good code and refactoring as necessary. Testing has just enough time to be thorough and because the devs aren’t rushed, less bugs are found in the first place. A few features may even be complete.
FP: Because of the approaching deadlines, sales and marketing guys are already starting to plan their demo’s and need screenshots and customer specific data set up. Anything that is not far enough along WILL be embellished during presentations, setting customer expectation too high. Code is sloppy as devs struggle to meet deadlines at any costs in quality. Testing is too short and bugs are missed, if happy path works, we move on. Functionaly, the product may seem to work, but just wait until later. Devs are getting tired, sick, and grumpy because they are working crazy hours. Everyone is putting pressure on anyone below them. Nobody is happy.
GP: Something has finally made it to a point where the end user gets to see it. At this point the company direction may have changed and that feature is no longer needed/relevant. Best case scenario is that no requirements have changed, even though maybe they should have, and you have a product that is on schedule. Devs are used to the lax timelines so they slack off and rush something out at the end. Testing finds errors and they redo it, still hitting deadlines. The code gets bloated and is overall of below-average quality.
End of Project:
SP: The product comes out pretty close to on time. Any differences in estimated and actual timing are noted and used for input into the next project. The features may not all be there, but we have something ready for market that is still viable. It will allow us to have another iteration of this product if its warranted. You are able to deliver 1 full working release of the product in X time. By 2X you have the 2nd version out with added functionality and increased customer base.
FP: The happy path is the only thing that works. You have missed all deadlines. Any significant load brings the application down or to a halt. Unexpected results in testing are still getting last second patches and bandaids by the dev team. Your best developer(s) has quit because he got burned out. There goes all the domain knowledge because no documentation was able to be made. You are so late your first version took twice as long as planned and releases in X time anyway. Out of your potential customer base, only a fraction buy the product because it is not what the salesmen described. The customers unfortunate enough to get stuck with it hate it for the lack of performance and stability. Your company has run out of money or will run out of money if leadership isn’t changed. To get the product to an actual usable state takes another release and major refactoring. By 2X you have a simple but mostly working product.
GP: The product comes out on time. It cost you a lot of money, and therefore costs a lot of money to buy. The marketplace may not really even want it anymore, and someone has put out something better for cheaper. You delivered a non-cutting-edge product with a huge budget in 2X. You are ready for the second version to try and catch up to the current market, that will take until 4X.
While this was a bit of a contrived example, most people can relate to at lesat one of those scenarios. From this we can see several conclusions. With SP your software will come out close to on time, and actually closer and closer with each new iteration. No one is burned out, and projects can continue at this exact pace, allowing the process to get more refined and accurate. SP requires intelligent developers who are commited to not taking shortcuts. Any slackers will be easy to spot and need to be corrected or fired quickly. Sub-par performance can’t be accepted. With FP you promise too much, fail often, waste a lot of money, and burn out any developer you would want to keep. Bad people stay and multiply because 1 crappy person with minimal domain knowledge is better than 0 on a project with looming deadlines. The code will never be good quality. With GP unskilled workers can thrive and blend in. The project may be ‘on time’ but in this day and age, the product will miss its timing in the marketplace. At best, you will always be a step behind.
I think this is pretty related to the way the entire business is run, not just the software side of things (like you said in the beginning).
In SP, expectations are realistic and understood that resources (time, money, people) are necessary to complete goals. They provide good environments for workers, and can attract people who want to have a good work/life balance (but provide solid contributions in both arenas).
In FP, you get the super smart college kids who become the leads. The more senior people slack off because they realize it’s going to go downhill anyways. The super smart college kids get egos and then eventually burnout, not realizing that the solution to most of their problems was to *think* and not just throw 12 more hours of code at it.
In GP, you just have to be better than average, and you have a nice, competitively paid job with good benefits, but no sense of accomplishment.
SP and GP can both be good depending on what you want to do. FP is the only one that always ends up ruining both devs and company, imo.