Goto Considered Unartistic

Software Development Isn’t an Art IV

For precept must be upon precept, precept upon precept; line upon line; here a little, and there a little. — Isaiah 28:10

The identification and use of design patterns has moved our understanding and the current state of our profession forward. But without an understanding of the critical factors for developing and successfully completing quality software projects, stagnation at the current state is all that can occur. And stagnation is all that’s occurring due to our unwillingness to exert more rigor in the design of software.

When Walt made storytelling the linchpin of his animated films, the other studios were unable to compete on a long-term basis regardless of the gimmicks used. They hired away his animators. They hired away his composer. They hired some of his storymen. But they didn’t use his process of refinement and experimentation to develop and improve the stories they told, and it reflected in the quality of their films.

Developing software without a written, documented and tested plan is like making a movie without developing the characters and the plot. Or, to use a metaphor you might find easier to relate to, like building a house without a blueprint. You’re just eyeballing it and you’ll have to continue making adjustments to your code as you integrate it into the rest of the system. And hope it works out for the best.

But you know it won’t. You know you”ll have to spend more time trying to get components to work together properly. You know you’ll have to redo production code and unit tests repeatedly. You know customers will change requirements that will adversely affect the system’s integrity downstream. Does it seem like a good idea to add extra work to your plate because you didn’t take the time to execute a proper design in the first place?

The design isn’t in your code. “If” statements aren’t design constructs. Neither are functions. They’re execution constructs meant for computers to execute.

Design languages help you understand and analyze designs. They help you switch contexts much quicker than code ever could. So when you design, use the language of design; don’t use code. Code is for computers to follow, not people.

Leave a Reply

Your email address will not be published. Required fields are marked *