Brian On Software

"No one can disparage the ability to write good code. At its highest levels, it is an art." Such is a quote that can be read on the back cover of Mike Gunderloy’s book, "Coder to Developer" from Sybex . I got this copy from the library thinking that I would learn something new, something deep about software development. In all of its 295 pages, I can say that this book is not geared towards the intermediate to advanced software developers, but rather to those who are beginning the road to become professional software developers. The main idea behind the book is that "software development" is more than just coding and compiling a software project. There are various activities, principles and practices to set up and to follow in order to design, implement, ship and support a software product. Although Mike’s book is targeting the .NET Framework and the Windows platform, there is no doubt that his point can be shared across other technologies, tools and environments. Joel Spolsky wrote the foreword, and I must say that it was a delight to read it. Here’s an excerpt of what he wrote that pushed me further in reading this book:

"We don’t really know what software development is all about until we have a concept, put in place a team, set up state of the art development processes, design a software product, the right software product, and produce it. That’s not all…it must serve a real need of its users and be accompanied by a web page, a setup program, tests cases, multilingual versions, etc."

I think one reason that I didn’t put this book in my top reading list of all-time favorites is because most of its content, if not all of it, can be found today on blogs and with the help of Google. As a matter of fact, the book was published in 2004, therefore most of the tools that are mentioned in the book are nowadays outdated, unsupported or altogether abandoned. Have I read this book back in 2004, it would have been a great source of insights, but now that we have the power of search in our hands, I don’t really see the pertinence of authors writing any more technical books tackling such a broad field with the support of different tools. Nevertheless, the ideas and principles covered in this book were concepts preached by advocates of software engineering for a long time and are still relevant today. For example, how many organizations today have an established automated continuous integration process? How many independent consultants know how to write a solid contract before embarking on a project?

The author defines a coder and a developer in these terms, which I think is well put:

A coder knows the syntax and semantics of a computer language, whereas a developer can apply that knowledge to turning out a working application with all the necessary supporting details.

I also like the preliminary questions that each developer should ask himself or herself before jumping in the adventure of creating a software:

Ask yourself these fundamental questions before starting to write your software:

1. What are you writing?

2. When do you want to finish writing it?

3. Where do you expect it will be used?

4. Why are you writing this software?

5. How will you write the software?

Someone willing to advance in this profession should be able to answer all these basic questions before engaging a new project. I like the way that these questions don’t depend on implementation or technology.

Mike also presents various ideas to keep in mind before starting to code. Two of my favorites are the concept of the Elevator Pitch and the checklist of eliciting requirements:

Write a good elevator pitch for your software before starting to code it. Keep in mind the following:

1. Short is better than long. A long and rambling elevator pitch probably means you haven’t really decided what you’re building yet.

2. Functionality trumps technology. Potential customers care about what your software will do. They usually don’t care how your software does it.

3. Solve a problem. If you can’t explain what problem your application will solve, customers won’t know why they should buy it.

4. Pitch the benefits, not yourself. Customers won’t be buying you, your superior knowledge, or your development team. They’ll be buying the software.

5. Figure out what’s important to your audience, and make sure you address that. Are the people buying your product most interested in cost, innovation, features, compatibility, or something else entirely?

Eleciting Requirements Checklist (if working with an external customer)

1. Talk to the actual end users of the software. Ask them what they expect the software to do.

2. Watch how the end users perform their job now. Make sure you understand how the software will change things.

3. Write a vision and scope document, explaining what’s a part of the project and (equally important) what is not. Make sure the customer agrees with you.

4. Hold an informal group discussion with the users over lunch or a night out. People will speak up in a group of their peers even when they won’t tell you things one on one.

5. Document the requirements in plain English, and then check with the users to see if they make sense.

6. If you’re replacing existing software, find out what’s wrong with the current system. Your requirements will often boil down to fixing the problems.

7. Arrange the requirements in priority order and make sure the customer agrees on the priority.

At the end of the requirements elicitation process, you should know what the software will do. Just as important, the customer should have confidence that you understand their requirements.

I was delighted to see that the author mentioned two other types of documentation that should be written whether we’re developing in solo or in teams. These are the development log and the postmortem. It is the first time I encountered the existence of these two documents, which proves that you always learn something new, even when you think you know it all (note to self…). In a development log, we tend to ask and answer the following questions:

• What the overall architecture of the application is, and why that architecture was chosen over alternatives
• Who’s responsible for each part of the application or for each function on the team
• Where key pieces of the network are located: Which server handles source code control? Which one is the build machine?
• What tricky problems came up, and how they were solved

This development log can easily be maintained in a wiki, a blog, a SharePoint site, etc. I believe this artefact to be very useful for new team members.

The second type of document that should be written is the postmortem. In this document, we tend to include the following:

• Overall description of the project
• Who was involved on the team
• How the project’s scope and features changed from initial design to final ship
• A list of things that were done well during the project
• A list of things that could have been done better
• A list of tools used, along with an evaluation of their quality
• A list of tools that team members wish they had had available
• A list of important project documents with their locations
• Recommendations for the next project: How can things be done better?

Whether you’re a student of computer science or software engineering, or someone making the shift to the software development field and looking for ways to advance as a professional, I’ll recommend you to read this book without hesitation. On the other hand, if you have "been there and done that" for a while and you’re looking to polish your skills, I’ll suggest you to keep looking around because chances are that you will learn more by reading what’s in the blogosphere.

In all, I think that Sybex has published a good resource for the newcomers in this field. Here are the topics covered in this book as stated on the back cover:

• Choosing and using a source code control system
• Code generation tools – when and why
• Preventing bugs with unit testing (and mock objects)
• Tracking, fixing, and learning from bugs
• Application activity logging (using various tools, including the Logging Application Block from Enterprise Library)
• Streamlining and systematizing the build process
• Traditional installations and alternative approaches
• Creating software documentation for users and stakeholders

On a final note, these are the contents at a glance:

• Chapter 1: Planning Your Project
• Chapter 2: Organizing Your Project
• Chapter 3: Using Source Code Control Effectively
• Chapter 4: Coding Defensively
• Chapter 5: Preventing Bugs with Unit Testing
• Chapter 6: Pumping Up the IDE
• Chapter 7: Digging Into Source Code
• Chapter 8: Generating Code
• Chapter 9: Tracking and Squashing Bugs
• Chapter 10: Logging Application Activity
• Chapter 11: Working with Small Teams
• Chapter 12: Creating Documentation
• Chapter 13: Mastering the Build Process
• Chapter 14: Protecting Your Intellectual Property
• Chapter 15: Delivering the Application

Verdict: 3/5. It’s a book aimed at beginners who have at heart the need to improve the way they work, as well as their sense of professionalism in the field. The intermediate and more advanced developers would gain more insights by reading what other experts are writing in their blogs and articles. Since the book is heavily dependent on various tools and technologies supported by the 2003 release of the .NET Framework and the Windows platform, most of the content can seem to be outdated and maybe completely irrelevant in a couple of years. Especially for those of us who don’t target the .NET CLR and the Windows platform.

Happy reading!