Since we've taken on 8 interns in Aista, and I am not sure about their experience level, and I need to be creative in regards to the process of following up on our interns - I wanted to write something publicly about waterfall software development. Why? Because the task they will be doing at Aista is to implement a working piece of software in 6 to 8 weeks, using the waterfall software development process.

"Waterfall" has a bad reputation. For software developers and architects it's almost a curse word. This reputation is really not justified, at least not for most projects. To understand why, let's first ask ourselves what waterfall is, for then to ask ourselves what the primary argument against waterfall is.

What is waterfall and BDUF

BDUF implies "Big Design Up Front", and is closely tied to the waterfall mindset, implying you start out with a big design describing what you want to build, down to the smallest detail. When you have created your design using for instance Figma or something similar, you start modelling your database. When you're done modelling your database you start implementing code wrapping your database. This is why it's called "waterfall" because the process moves in one direction, the same way a waterfall does, and the assumption is that you can't go back and change your design after the process has started. The argument against waterfall is as follows.

If you don't get the design correctly applied initially, the project is bound to fail, since it doesn't accommodate for change in the requirements after the project has been initiated.

However, the assumption that waterfall is a "one directional process" is simply not true. Just because you're using waterfall as the primary process for your project's delivery, doesn't imply you cannot change the rule parts of the time. Hence, claiming that waterfall doesn't allow for change is simply not true.

The second point is that if you already know more or less exactly what you want to create, having a BDUF will lubricate your software development experience, resulting in that all your team members can work more autonomously, with fewer meetings to collaborate with each other, since everybody knows what they're supposed to create - At least more or less. With a pure Agile software process the only thing you'll achieve is to spend all your time in meetings quarrelling over use cases trying to integrate other developers changes into your own parts.

The third point which is somewhat unique to Magic, is that if you've got a database design that's accurately applied to model your project's requirements, Magic literally creates your code automatically using the database schema as a "formal specification", wrapping a CRUD API around your database tables, for then to optionally create an Angular project for you.

Everything that can be formally described can be automated

To illustrate the problem with Agile here, imagine telling Toyota's car robots the following; "Yeah, we're about to create some cars, we don't know how many wheels they'll need, and we don't know what engines to use - But feel free to 'change this' as the owner's requirements 'changes over time'". This is the Agile software development process applied to car manufacturing.

Needless to say, but the above of course is madness. Still we tend to take it for granted as the only sane software development process, while it's really quite insane ...

If you're telling me Agile is so fantastic, go build a house using the "Agile software process"

If you have no idea what to create, my advice is to ask the customer questions, and spend more time in the project investigation phase instead of starting out by implementing use cases.

PLAN what you want to create! Plan it WELL!

Modularity

The idea with Agile software development, is that instead of using BDUF, you have the customer feed you with use cases. The problem with this approach of course, is that you'll need to implement everything in a modular approach, where everything might potentially change, and unless everything accommodates for this future change, you'll have to re-implement the same thing dozens of times to accommodate for this change. Unless you want to re-implement everything multiple times, you're forced to creating a design that is so modular in its approach, that you end up adding 10 additional layers of abstractions on top of your thing, where most of your implementations needs to be re-written further down the road, creating breaking changes to the app as a whole, all the time. Basically, your process becomes a never ending cycle of having to apply breaking changes to your project.

A "pure" Agile software development process inevitably leads to the Big Ball of Mud

Yet again, if you don't believe me, try to create a house using "use cases" and "Agile processes". How many doors do you think you'll have to discard if you do before the customer is happy you think? And sure, you might have a door and an entrance, but there's no guarantee of that the door is correctly applied. Below is a house that might have been implemented using an "Agile house building process". I'll leave it up to to my readers to see the problem here ...

Similar results will be experienced if you implement software exclusively using the same process. The funny thing is that if you break the above house down into its use cases, it's probably a perfect match from the software developer's point of view.

1. It's got a door - Check
2. It's got a roof - Check
3. It's got windows - Check
4. Etc, etc, etc ...

The fact that the house was delivered upside down is from the software developer's perspective irrelevant, since he or she perfectly implemented every single use case the customer had. Ironically, the customer can't even complain about the delivery, since the software developer can prove he delivered exactly what the customer told him to implement ...

Waterfall vs. Agile, the showdown at dawn

Facts are, neither of these processes are correct. The truth is as always somewhere in between. Do as much as possible using waterfall, but as you do make sure you accommodate for change as the customer gives you feedback. If you can do everything using waterfall than prefer it, because it's simply superior in every single regards. Below is a building that was created using the waterfall process to illustrate its beauty.

Conclusion to my student interns

Spend more time up front designing and modelling what you want to build, because the more time you spend up front, the more likely it is that you'll deliver something useful. Then only when absolutely necessary resort to Agile and change. Don't fall for the "Agile Kool Aid". The world has enough garbage software projects as is ...

When you know exactly what you want to create, most of the job is already done!