"When it's Done" or "Two More Weeks" is No Way to Run a Software Project
I'm going to pick on something this week, namely "when it's done." As in, "it'll be done when it's done." Or, "it'll be done in two more weeks." These phrases used to be common in the Amiga computer community, and basically meant software development with no deadlines. No deadlines is a bad idea...
- Having no deadlines is an alluring idea. After all, estimating how long a software project will take is hard to impossible, so how about you ditch the deadlines and just let us do the work until it's done?
- I don't like deadlines either, but having none is a bad idea; it's dangerous
What would've happened to Warp3D Nova Without Deadlines
- Warp3D Nova is a modern 3D shader based graphics system for AmigaOS (plus drivers)
- If I hadn't had any deadlines, then I would have...
- Dreamt and thought about all the feature's we'd eventually want to have
- Tried to future proof every design decision
- Spent ages agonizing over every design decision, and still end up making non-optimal decisions because I simply don't have the information I need to know what the future holds
- Over-engineered everything
- The project's scope would have grown and bloated
- Then, Warp3D Nova would likely have collapsed under its own weight, and AmigaOS 4.x users would still be waiting for someone to deliver a modern 3D graphics system
What Actually Happened
- I had milestones with deadlines (private ones, but still deadlines)
- This forced me to focus:
- Which features offer the end users the most value?
- What's most important? What really matters?
- What's essential? What can be delivered later?
- It sped up my decision making because I don't have the luxury of over-thinking
- I got the first version into the hands of other developers much faster
- Some of the initial feedback was pretty harsh, but getting feedback early was essential to making a good product
- Warp3D Nova would not be anywhere near as good as it is now without deadlines and getting end-user feedback early
- If deadlines are too scary, then call it a "target date" instead
- Deadlines/target-dates don't need to be public (many of mine aren't)
- I do recommend that someone else knows about the deadline and is there to keep you accountable. Otherwise, it's too easy to let it slide
- Make sure that the deadline is realistic. If you don't believe it can be done, then you're not going to try. So make sure that you believe that completing by the deadline/target-date is feasible
- The biggest benefit of deadlines/target-dates, is that it prevents feature creep and "sky high" dreaming from derailing a project. So, you're less likely to work for a long time on a project, only to discover it isn't what end-users need or want
Fred Booth 11/05/2020 10:34am (3 years ago)
ROAR 11/05/2020 9:31am (3 years ago)