He said, "Many new programmers have the Goz-Inta problem, they don't know what should Goz-Inta what!" New programmers write programs that consist of one gigantic function. It doesn't occur to them that some of that code should goz-inta separate functions. They don't have any experience with reasoning about what should goz-inta what. And more than that, it doesn't even seem to be an important issue. After all, working programs is the most important thing, right? HA!
From the time that I emerged out of the "new programmer" phase, I have found that all the major problems of "Software Architecture" can be reduced to questions of Goz-Inta. People seem to progress through the following stages:
- 1 big function
- 1 big class
- 1 big assembly
- 1 source control branch (as in, no branches)
And that's not all! Take a look at design smells/patterns/principles. What are they all doing? They're either describing symptoms of Goz-Inta mistakes, common Goz-Inta techniques, or big picture Goz-Inta concepts. GOZ-INTA.
Ever heard people say that its important to name your methods and classes well? That's because a good name helps the author remember what should and shouldn't goz-inta those methods and classes. A good name also helps people using the methods and classes understand what's gonez-inta them.
Why do I think that unit testing helps you design better code? Its because unit testing forces you to think about the Goz-Inta problem.
Furthermore, in my experience, the best programmers are the ones who are the best at working through the trade offs created by the Goz-Inta problem.
I agree. From a programmer's perspective, much of work isn't only how to do something, but where to put the stuff that does that something.
ReplyDeleteAs I work to add new functionality to a legacy system at my current client, I am pushing for a higher awareness of the code's "intended behavior". I think the first step is to name/label/comment your code so that the intended behavior of the code is easy to understand. I would rather think that operations 1, 2, and 3 should be separate but KNOW that method A does 1, 2, and 3 or fails.
By focusing on separating concerns, focusing and documenting behaviors and making sure that your code is honest ... at least your code can be understood by other programmers. And the fact of the matter is ... while a computer may execute your code millions of times, it always executes it the same way. Human understanding of intentions is full of gray areas and attention needs to be focused on making sure other humans understand what you were trying to do AND if you did it right.
(hopefully the above makes sense, it was written quickly before a meeting :) )