C H A P T E R  16

Wrapping It all Up

All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists.

—Frederick Brooks, Jr.¹

It's the only job I can think of where I get to be both an engineer and an artist. There's an incredible, rigorous, technical element to it, which I like because you have to do very precise thinking. On the other hand, it has a wildly creative side where the boundaries of imagination are the only real limitation.

—Andy Hertzfeld

Reading Alex E. Bell's² and Mark Guzdial's³ “Viewpoint” columns in the August 2008 issue of Communications of the ACM, I was struck by the synergy of the two articles. One is a cautionary tale about the tools to use in professional software development, and the other is, at least in part, a cautionary tale about language and syntax use in teaching programming. This got me to thinking about all the silver bullets we've tried in both development and education, and why most of them don't matter to real software development. This seems like an appropriate way to wrap up this discussion on software development.

__________

What Have You Learned?

As I've said more than once in this book, software development is hard. I don't think that everyone can do it, and of those that can, I think few do it extremely well all the time. That, of course, is the attraction. Nobody really wants to work on easy problems. The challenge is to work on something you've never done before, something you might not even know if you can solve. That's what has you coming back to creating software again and again.

Software development is one of the most creative things a human can do. Out of nothing, one takes a problem, wrestles with it, explores it, pokes at it, rips it apart and puts it back in a different form, comes up with that bit of inspiration that leads to a solution, and then converts it into an artifact that others can use effortlessly. Having others use your program to solve their problems is just the coolest thing.

Writing software is a humbling experience. It is so hard to get software right and so easy to get wrong. In writing software, I've learned to embrace failure. Failure is an exciting and frustrating part of the process. From failure, you learn about yourself: you learn how you approach problems, you learn the types of mistakes you're prone to make, and you learn how to work around them. Failure teaches you perseverance because you just have to keep working until the program does.

Small teams build most software, and they build the best software. Small, highly motivated and empowered teams are the most productive. Small teams also tend to use a slimmed down development process. Unless you work for a large company that's desperate to be at SEI Capability Maturity Model Level 5,⁴ your processes can be very sparse. Detailed problem descriptions, brainstorming design sessions, simple configuration management, code reviews, and a separate testing team take care of everything necessary to create almost defect-free code. Process flexibility, communication, and ownership are the keys to project success.

A lot of really good software gets written, tested, and shipped every year; much more than the alleged “failure” numbers would have one believe.⁵ The key issue that divides plan-driven development and agile development is the recognition of the constant changes in requirements. The best thing about agile development is that it recognizes this fact and builds refactoring into its process.

Simple tools are the most effective. Simple tools allow you to cut to the heart of a problem and examine it closely with nothing in your way. They allow you to take it out, hold it in your hands, turn it over, and poke at it quickly and easily. Simple tools also allow you to join them together to do more complicated things. I'll just point you to Stephen Jenkins' article on “Old School” programming.⁶ He's said it much better than I could.

Coding, debugging, and unit testing are at least as important as design. Experience gives a good programmer a deep sense of design and a wealth of patterns to draw on; experience gives a great programmer a deep, intimate knowledge of the programming language that is their tool. It's this deep, intimate knowledge that produces beautiful code.

The process of debugging a long, complex program is an immensely rewarding endeavor. Isolating a problem, uncovering your mistakes, building debugging scaffolding, hypothesizing a solution, reworking a design, finally identifying the error, and then creating a correct fix gives one such a rush of elation and satisfaction that it's at times nearly overwhelming.

__________

What to Do Next?

So now that you've read all about software development and maybe tried some of the examples, what do you do next? How do you become a better software developer? Well, here are some suggestions.

Write code, write lots of code: Experience helps a lot. Programming is a craft that requires practice and constant reinforcement. It's very likely that you'll need to learn a whole new set of tools and programming languages every ten years or so. So having written lots of code will make that task easier.

Learn simple tools: Simple tools give you flexibility. They also help you learn the fundamental skills that you can then take to more complicated IDEs. And when those IDEs get replaced – as they will – you can fall back on the simple tools till you learn the new IDE.

Read about problem solving and design: People have been solving problems for several thousand years now and people have been designing things for nearly that long. Writings in other areas can communicate common problem solving strategies that also work for software development. Don't ignore Polya's How to Solve It book. It was written to solve math problems, but it translates very, very well to software.⁷ Also don't ignore the classics in the computer science literature, like Dijkstra's Structured Programming book,⁸ Brooks classic The Mythical Man-Month,⁹ Bentley's Programming Pearls,¹⁰ McConnell's Rapid Development,¹¹ and Beck's Extreme Programming Explained.¹²

Read about programming and read about programmers: There is a plethora of literature on programming. A number of books have been mentioned in the previous chapters. Two that bear repeating are Hunt and Thomas' The Pragmatic Programmer¹³ and McConnell's Code Complete 2.¹⁴ It's also a great idea to see how other programmers work. There is a developing literature in computing on how great programmers think, work and generally write great code. Two notable books are Lammer's Programmers At Work¹⁵ and Oram and Wilson's Beautiful Code.¹⁶

__________

Talk to other programmers: Books are an okay way to gather information, but talking to your peers can't be beat. A side effect of pair programming is that you get to see how someone else works, how they approach problems, how they code, debug, and write tests. Code review meetings are a great way to learn how others work. Code reviews also reinforce Gerald Weinberg's idea of egoless programming.¹⁷ Once you get over the idea that you “own” the code in a software product (your employer owns it; read some of those documents you had to sign on the first day of work), you gain the ability to look at your code and the code of your co-workers objectively and you can learn from it.

Join the ACM and the IEEE-CS: The Association for Computing Machinery (ACM) www.acm.org and the IEEE Computer Society (IEEE-CS) www.computer.org are the two main professional organizations for computer scientists. Their journals contain a wealth of information about all things related to computers and computing, their conferences are worth attending, and online they have free books and courses for members. You will not regret joining one or both of them.

Be humble: The following quote from Dijkstra says it all. Software development is hard. Programs are very complex, and programs of any size are extremely hard to understand completely. Besides being one of the most creative things that humans have ever done, computer software is one of the most complex. Be humble. Work hard. Have fun!

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility...

—Edsger Dijkstra¹⁸

And lastly, I couldn't resist a quote that had both the words magic and computer in it...

The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.... The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.

—Frederick Brooks

__________

References

Beck, K. Extreme Programming Explained: Embrace Change. (Boston, MA: Addison-Wesley, 2006.)

Bell, A. E. “Software Development Amidst the Whiz of Silver Bullets,” Communications of the ACM, 51, 8 (August 2008), 22-24.

Bentley, J. Programming Pearls, 2nd Edition. (Reading, MA: Addison-Wesley, 2000.)

Brooks, F. P. The Mythical Man-Month : Essays on Software Engineering, Silver Anniversary Edition. (Boston, MA: Addison-Wesley, 1995.)

Dahl, O. J., E. Dijkstra, et al. Structured Programming. (London, UK: Academic Press, 1972.)

Dijkstra, E. “The Humble Programmer,” CACM 15(10): 859-866. 1972.

Glass, R. “The Standish Report: Does It Really Describe a Software Crisis?,” Communications of the ACM, 49, 8 (August 2006), 15-16.

Guzdial, M. “Paving the Way for Computational Thinking,” Communications of the ACM, 51, 8 (August 2008), 25-27.

Hunt, A. and D. Thomas. The Pragmatic Programmer: From Journeyman to Master. (Boston, MA: Addison-Wesley, 2000.)

Jenkins, S. B. “Musings of an ‘Old-School’ Programmer,” Communications of the ACM, 49, 5 (May 2006), 124-126.

Lammers, S. Programmers At Work. (Redmond, WA: Microsoft Press, 1986.)

McConnell, S. Rapid Development: Taming Wild Software Schedules. (Redmond, WA: Microsoft Press, 1996.)

McConnell, S. Code Complete 2. (Redmond, WA: Microsoft Press, 2004.)

Oram, A. and G. Wilson, Eds. Beautiful Code: Leading Programmers Explain How They Think. (Sebastopol, CA: O'Reilly Media, Inc, 2007.)

Paulk, M. C. The Capability Maturity Model: Guidelines for Improving the Software Process. (Reading, MA: Addison-Wesley, 1995.)

Polya, G. How To Solve It: A New Aspect of Mathematical Method, 2nd Edition. (Princeton, NJ: Princeton University Press, 1957.)

Weinberg, G. M. The Psychology of Computer Programming, Silver Anniversary Edition. (New York, NY: Dorset House, 1988.)