Yesterday, we talked about the First Tenet of Software Development and some people didn't like it. They thought it was too simple.
Let's see what you think about the...
Second Tenet of Software Development
Everything the program is supposed to do must be known by the software developer.
Just as the designer of the board game has to know exactly how the rules work so she can create the game, so too the software developer must know what the program will do so she can create the code.
Immediately, A Problem Arises
Here’s the problem. A lot of what we just talked about in the description of the Pac-Man board game seems obvious. It’s the nature of how human brains work.
“Of course you have to roll dice,” someone says. “How else would you know how far to move Pac-Man and the ghosts each time?” How things should be done may seem obvious to one person on the team. Those requirements that seem so obvious may not even be discussed much. The problem occurs later when the obvious assumptions are actually different in various team members’ minds.
Without Detailed Definition, The Developer Does It His Way
Maybe the Pac-Man board game doesn’t use any dice. Maybe the ghosts move X units every time. The point is that without the actual explanation and description the game builder (analogous to software developer) may do it however he decides. However, his way may be completely wrong.
Designer & Builder: Two Different People = Challenge
If the designer and the builder are two different people, the builder’s decision may be entirely wrong. Furthermore, unless the design element is described properly it may force the developer (builder) to make a decision that she believes is correct. For example suppose the description for movement is something like the following:
Each turn, each ghost will move a random number of units in a random direction.
No maximum movement has been defined so now any ghost may move up to infinite units in a direction. So now, the game is created and Pac-Man moves, then a ghost moves infinite units towards Pac-Man and destroys him every time.
That’s ridiculous. I know. But let’s circle back to the original definition of what Software Developers do:
Developers write code to turn manual processes into automated processes.
Automate the Wrong Process
Now we are seeing that if the manual processes are not described properly or are not described at all, the software developer (builder) can automate the wrong process. Or, she can automate the process the wrong way.
That’s why an important part of Crafting Software is : Communication.
That'll be the subject we'll talk about tomorrow.
How can a person best communicate what they want built? It's a real challenge. This book, The NextLevel Software Developer will detail exact deliverables you will want to provide to create the best communication possible.
Top comments (0)