It could be project planning, architecture, or design. Whatever it is you'll often hear people say, we would do it but we don't have time.
Project planning, architecture, and design all share a common property. Work proceeds faster and more reliably if they are done in advance. The obvious cliche that can be thrown back is, "Hey, you don't have time NOT to do planning, architecture, or design." But we are want a bit more than cliches.
Project planning is the act of identifying the work to be done and resourcing it. (The word project means to pro-ject, to look forward.)
Architecture is the act of identifying the constraints you will be placing on the system.
Design (in general terms) is the act of deciding look and feel and the user experience.
Can you reasonably go to your management or investors and say, we didn't plan out the project and we have no idea how we are going to resource it? We don't know what we are building because we don't have time?
When you write code you are constraining the system. You are choosing to write this code not that code. Those are architectural decisions. Your system will end up with an architecture. The question is will it be a known architecture or an accidental one?
Emergent design gets mentioned from time to time, and it certainly happens. People have conflated benefiting from emergent design with capturing the system constraints once they exist. Even if an aspect of your architecture were to "emerge" wouldn't you want to capture that somewhere other than code?
Emergent design gets mentioned from time to time, and it certainly happens. People have conflated benefiting from emergent design with capturing the system constraints once they exist. Even if an aspect of your architecture were to "emerge" wouldn't you want to capture that somewhere other than code?
If the only place your constraints are captured is code, then two things are true. First, only someone who can read the code can know the constraints. Second, when the person that understands the constraints leave the team, that knowledge is gone and the constraint must be extracted from the code by the next person. Adding to this problem is that there are many things in code that form aggregate ideas and don't live in a single line of code, but rather the style or placement of the code. In other words, these aggregate ideas live across the entire body of the code.
These ideas require someone to read all the code to understand them. When reading a novel, it's hard to tell the traits of the characters from any single line of the story. We come to know that the characters are "good" or "bad" over paragraphs, chapters, or sometimes even the entire book. The same can be said of certain system constraints (architectural constructs). Can you really tell if a method is part of a transaction by looking at the method? Or do you have to look at every potential caller?
Design is similar. If left to the wind you'll end up with as many designs and flavors of user experience as you have developers.
The question is not whether you have time to do these things, it's whether you have time to let them happen chaotically and at the whims of every team member. You're not going to look very good when it comes time to explain that this was the choice you made.
The question is not whether you have time to do these things, it's whether you have time to let them happen chaotically and at the whims of every team member. You're not going to look very good when it comes time to explain that this was the choice you made.
If you do some project planning, architecture, and design up front there is another important aspect that you can employ. You can get the plan, architecture, and design approved BEFORE it's built. In fact, the more of these things you do (within reason) the better off you'll be at getting the project sponsors to understand what's going on with the project.
