I’ve worked on many projects and all of them had deadlines. And like any other developer, I consider deadlines very annoying as they get closer and closer, forcing me to work more and procrastinate less. The result tends to be an uneven workload, since things are reasonable quiet when the deadline is in two months and extremely busy when the deadline is at the end of this week, and it’s already Wednesday. Deadlines can be especially nasty if someone estimated a task to take three weeks while it turns out to be two months worth of work. Or worse, it’s two weeks of work, but other tasks in the same period also expand to two weeks work. Thus, if you have 5 tasks that each take two weeks, and you have three weeks in total, then you’re doomed before you can even start…
But while deadlines are Evil, we just can’t work without them. At least, as long as we want to receive our paychecks, we can’t do without them. Why? Because to create a project or to upgrade an existing one, an X amount of money is reserved to cover all development costs. The final deadline is calculated based on the amount of money that is invested in the project, minus the amounts of money that those paychecks will cost. (Plus many other costs…) Once this deadline swooshes by, the product will have to generate revenue so new projects can be started. Else, the end of the deadline will probably mean your paychecks will stop too. So, it’s important to finish within those deadlines.
I can’t help thinking about the Cathedral and the Bazaar, an essay describing the differences between open-source and closed-source. It fits the area of deadlines too, since bazaars are built by people who feel inspired to build just a small piece of something large. And when they leave, others can take over. As a result, thousands of people can work on building the Bazaar and while the final result might be chaotic because of all the style and color differences, it’s also something that’s build quickly and without any deadlines, simply because others will fill in the spaces of those who don’t make it in time. Then again, many people working on those bazaars won’t get a paycheck, just some recognition of being part of a larger community.

Building a Cathedral, however, is a very long process which used to take decades or even longer. Things had to be carefully planned and everything needed to be finished in time, because other parts need to be built on top of the first parts. Not making the deadline often means it would take longer for the cathedral to be finally finished. Fortunately, most Cathedrals had near-infinite funds because people knew it would take decades to finish even before they started building. Thus, they would find investors to start things up by donating money in return for promises in the afterlife. Which makes a very wonderful sales argument, by the way. Besides, if for whatever reason the construction of a Cathedral could not continue, people would change the build plans or re-use whatever had been built for something else. Here, deadlines matter but because the financial resources were almost infinite, there was never a real, final deadline.

Unfortunately, software developers generally want to be paid and don’t have infinite resources. Thus, we have to deal with final deadlines far more often. Which is why development methods have been created to make sure that there’s at least something finished at the end of a deadline.

When I was young, I’ve learned a technique called SDM, which is based on the seven stages of action. This method is often referred to as a waterfall method and is often considered outdated because people today expect software development to be “rapid”. In SDM, each stage could take a few weeks to finish and only in the 5th stage you would have some real code that would do something. Then the 6th stage would start all kinds of tests and if those tests failed, you would have to go back to stage 5. And if there was a design flaw, you might even have to go back to stages 4 or 3. Thus, it could easily take months before a company would see some results.

A modern approach is called Agile and basically it’s different from the old-fashioned waterfall technique because now you’re dealing with dozens of small waterfalls instead of one big one. And every waterfall has its own final deadline. A moment when you have to stop working on it simply because you’re out of resources. Unfortunately, if agile methods aren’t implemented correctly, they tend to fail quite hard and you will miss plenty of deadlines. This is mainly because these methods are created to generate results fast, even though the results themselves are small.

When done correctly, Agile will start to generate a very small project that has almost no functionality and isn’t much to look at. As time passes, more and more functionality will be added, which is possible because customers start paying for the product. (Or other forms of income are generated.) These customers will make extra demands and by using agile methods, the developers make the product comply to those demands within a reasonable amount of time.

But Agile will go wrong if developers start writing code too early or when management fail to estimate how long certain tasks will take. Worse, unlike the old SDM Waterfall method, the developers have no idea what the product should look like in two years. With SDM, they will. It’s just that with SDM you won’t have a product before this time, while agile methods will allow you to get customers involved in an early stage.

Agile methods also have another advantage. You are allowed to miss some of the deadlines, which just means some functionality won’t be implemented. So your project will e.g. miss functionality to export to Excel. It’s not that big of a deal, since you can always decide to try again after some time. But before you can do that, you will have to build up your resources again and analyze what went wrong. With the SDM methods, you might discover that exporting to Excel isn’t possible for whatever reason, thus you might have to go back a couple of stages to redesign this part. And going back means the whole project will be delayed longer.

So, let’s look at several scenarios with deadlines in them…

The deadline was yesterday.

Well, too bad. The project has failed. If you used SDM then start looking for another job since your company will most likely run out of its resources. Of course, there’s still a chance that they find some more investors thus the deadline might get extended. If that’s the case, the deadline just wasn’t final.

If you used agile methods then your product will be missing a feature. This is less costly and maybe you can keep your job but this is also the moment when people have to analyze what went wrong. Too much procrastination? Bad management? Bad planning? Or just too many surprises and unexpected events?

I have seen how a scrum sprint of three weeks contained work for 4 developers. Each of them would have to work at least 32 hours per week. Unfortunately, it was planned during the holiday season around Christmas, and two of the developers had taken two weeks off. One three weeks and the last one would be available most of the time. Management knew about this all months before the sprint would start so it was already doomed before it started. To make it worse, the developers would still try to get a lot of work done, thus coding started without much thought of any logical design and the code just became a bigger mess than it was before. Bad planning because of bad management that results in bad code. This can haunt the future of the project since the next sprints are unlikely to contain tasks to fix the problems that occurred during this period.

When you’re not finished at the end of the deadline, it’s important to analyze why it failed and if there’s anything usable produced which could help to redo this sprint. The code needs to be frozen and put on a sidetrack (a separate branch in your source control system) because the next sprints will have to be done. In the worst case, the other sprints are depending on the thing you were supposed to build, thus you must restart it all over again, causing an extra delay for the final delivery of the product.

The deadline is at the end of this week, and its Wednesday.

If you’re using SDM methodology, this will mean a certain doom, unless the product is finished and the testers can test it within the remaining days and don’t discover any bug. I have better luck with the horse races when I bet on the three-legged horse, but okay… It could happen. You can also try to deliver an untested product to your customers, which happens often enough. It’s a gamble but it might give you a chance to get more resources which will allow you to fix anything your customers find. Then again, if the bugs are really nasty, customers might claim their money back and might even sue for damages caused by your product.

When you’re using agile methodology then this means this sprint will be the last one so you should start working on fixing any major bugs and forget about adding new features. Disable and hide anything that isn’t implemented and if you can’t fix certain bugs in the last days, consider the possibility of hiding the options that cause the bug. Your customers are waiting and you’re now in damage control mode.

However, if you used the agile methods correctly, most of the features that are supposed to be in the product are available. Most bugs have been fixed already as part of earlier sprints. Most functionality should be available, even if you were forced to skip a few sprints. Just remember that this is not the moment to add some new functions. Quite the opposite! This is the moment to disable all that’s not working!

The deadline is over two weeks.

If you use SDM methods then you should be in the last stage, which is called ‘Implementation’. Basically, this is the final test phase of the whole project and things should work just fine. If bugs are encountered, they should be small and you should just test to see if the project is doing what it’s expected to do. Minor bugs can still be fixed or even ignored but any changes of the code should have a very minor impact. If you do find severe bugs, you will have to go back one stage, which will cause you to see the deadline pass by before you have a final product. But you will have a chance to fix those bugs and deliver the product with those fixes untested. Hopefully, those fixes didn’t cause new bugs. If they do, angry customers will tell you about them!

Agile methodology will have sprints of two or three weeks so this is your final sprint. You should not be adding new features at this moment because they might add new bugs. Those new bugs are normally fixed during the next sprint, but this one happens to be the last. The final sprint is better used to fix the most serious problems and have them tested so you know the final product will be okay to deliver to your customers.

All projects will have bugs so don’t be afraid if your product has a few. The deadline is there to show when you run out of resources and by delivering the product, you can gain some new resources. If you used agile methods correctly, most bugs will be minor and you will have added plenty of new functionality to please your customers.

The deadline is the next month.

Using SDM methods, this means that you will move from ‘Realization’ towards ‘Implementation’ thus if some features are still missing, then you’d better consider if those are really needed. This time will tell you if the design that you created during the first stages are good enough for the final product. Worst-case scenario? A design flaw, causing you to go back at least 3 or more stages. Still, at this moment you can consider moving to agile methods and fix things within one or two sprints.
When you’re using agile, you can consider adding a few minor functions to the product and you should start testing in an environment that resembles that of your customers. Don’t try to come up with new things and keep the developers available so they can quickly fix things before the final deadline.

I’ve seen the error of companies who decided to let developers work on the next sprint which would be part of the next version of the product. This is not a good idea because if something goes seriously wrong in the current development versions, those developers will have to switch back to the code base from before the new development. Worse, that new sprint will most likely fail too because those developers can’t work on it. Do keep in mind that resources will stop when you’re passed the deadline and your product isn’t ready to be delivered.

Of course, many companies will have some reserves that will allow them to delay things a bit more, but customers will be unhappy about this, too. They expected a product at the end of the month and now learn that they might have to wait another two to four weeks, at least.

The deadline is within a half-year.

Well, with this much time you can start making careful planning and do a few designs and exchange ideas before you start developing. If you’re starting something new then it might even be a good idea to use SDM methodologies with a deadline set at three months in the future. While it’s a single waterfall, it’s very likely that you want to start the project with a good base of functions. It’s no use if you have a product within a month that allows users to just enter a bunch of data without any other functionality, and with a crappy GUI. Besides, if you do manage to create a working product from scratch within two scrum sprints, then what’s the difference with the old-fashioned waterfall way anyways? Okay, you’ve had two smaller waterfalls. Most likely it won’t be enough to appease your customers because it’s a product that still leaves a lot to desire.

Still, agile methods would also work fine, because those customers can start adding their desires to the final design. You would have to start small and have a way for your customers to offer lots of comments. It won’t really be your product because your customers will dictate some of its functionality. Then again, that’s how agile methods work. They offer customers an early peek view and allows them to become part of the process.

Which also tends to cause problems with agile, because an important customer might ask for functionality that’s complex and takes long to deliver. To keep this customer, you would have to add this, but your other customers might prefer that you start with other features first. Management will have to read through all those demands and will have to decide which ones can be done before the final deadline, and which ones are for the next version.

Do keep in mind that I don’t mean the end of a sprint with ‘final deadline’. The final deadline is when you will have to deliver something to your customers because you’re running out of resources.

With SDM, you can still show a design to your customers and ask if they have any more comments. You can continue with these design stages until you reach the ‘Realization’ part. At that point, you should have enough information about what you want to build, what the project should look like, what your customers are expecting and you will be able to divide the remaining work into short sprints for the next three months. Up until that moment, you would have more need of your designers while your developers can just be procrastinating or whatever. But once you start to realize things, using sprints will at least make sure that you will reach part of your final goals.

Agile tends to fail also because of a lack of vision. You can start with a small project, then listen to the desires of your customers and add more functionality. But sometimes you want to create something big, like a CRM product for supermarkets. Sure, you could start small with a simple CRM product, but then it’s likely that those big customers aren’t interested and you’ll end up with lots of small fishes with lots of small desires. Still, plenty of small fish will offer enough resources, as long as you can keep them nibbling on your bait.