By Jeff Gainer
Updated 5 May, 1998
In the coming months, I’ll be posting selected draft chapters of my new work-in-progress, Lucid Code: Taming Software Development Chaos at this site. Let me know what you think. I’m seeking comments, suggestions, feedback, and war stories from members of the software development community.
Lucid Code is a book about software quality. Although there are already quite a number of books about software quality available, most concentrate on the theoretical aspects of building a software quality process, rather than the day-to-day mechanics of enacting it. Lucid Code is a practical guide for project managers, technical team leaders, and programmers on how to create and manage a process for building high-quality, maintainable software.
If you are a software professional, you know how software is created. Surely you recognize it. Chances are you live it: chaos.
If you're a developer, you know how it goes: The requirements just got changed after you've put all that work into the new interface. And it's just been tossed in the can because the client wants something different now, and—by the way—they need it tomorrow. Just a prototype you understand, but you have to put something together now.
Meanwhile, you've written some cool stuff you're like to keep for the new version, but there wasn't time to put it into an object, because the first time around you didn't have time to write it properly, so you just put it together and tinkered with it until it sort of worked, intending to do it right later. You can always go back and fix it later…when you have time….
So you skip lunch and go back to the code, intending to salvage some of if and then you realize you've got cryptic little notations. . . and why did you rem that out and what the heck did that module do, anyway? And--oh, no—that's not a variable, it's some kind of object…well, and that part's not quite the way it should be…it's not beautiful, but it finally works. But then after you wedge it into the new prototype it doesn't work at all and you blow a whole afternoon figuring out that –oh, yeah—it was just a simple scoping problem. Why didn't you see that before?
And now the whole afternoon is gone and you haven't completed any real work and you're going to have to work late again, really late. Better make more coffee and call for a pizza. It's going to be a long night.
If you're the development or project manager, the situation isn't much better. The client just made those suggestions, and you agreed, they had merit, but there is the schedule. Don't worry, you're told, just get the developers to put in some overtime….but that cuts into the budget, so maybe you could cut back a little on the testing time….
If you recognize this scenarios, keep reading. This book is for you.
Software is not supposed to be written this way. It doesn’t have to be written this way.
Despite the ever increasing demands for better, faster, cheaper development, you can control the chaos. It is possible to be a better manager, a better developer, producing better quality code with fewer errors. And you can meet deadlines. You really can tame the chaos.
Whether you are a developer or manager, Lucid Code will address the issues you face every day. If you’d like a preview of another part of the book, Contract Professional has published "Write Lucid Code" in their November/December 1997 issue. The article discusses the specifics of coding conventions and walkthroughs. Also, be sure to take a look at Visual Basic Programmer's Journal; they published my VB-specific article "Write Lucid Code" in their April 1998 issue.
Topics to be covered in Lucid Code will include:
Software Development Chaos: Defining the Problem
Quality Control –Testing Essentials
Annotated Bibliography
You can follow the links above to read a detailed outline of the book. And, as I mentioned above, I will rotate occasional full chapters here at this site prior to publication.
|
Please send any comments to Jeff Gainer. |
|
Copyright © 1997 by Jeff Gainer. All rights reserved. |
|
|