There’s not enough space or time to include all of the best practices of software development here in this book. I can just point you to other books specifically about that, such as Rapid Development by Steve McConnell. What I will do here is outline a few things that are important and will help you in your development work to make life easier and more efficient.
Maybe Something in Plaid Design work is vital to your coding and development work. I’ve had too much work become much more difficult due to bad design work on my part or others to give short shrift to the design at the beginning. The amount of design work to perform should be proportional to the amount of work you’re talking about. At one company, things were going a bit overboard on the design side. At one point we joked that in a few years we would spend our 10 month development cycle doing 8 months of design work to decide which single line of code to change. We would change that line of code in an hour and then test it and document it for the next two months.
Of course, this is a bit of an exaggeration, but there’s a time to design and a time to code. Spending them efficiently and wisely is a delicate balancing operation. I’ve spent an hour designing small changes and weeks designing large systems. The amount of code and the impact to the system are important in deciding how much time to spend in design.
One thing I recommend is that, if possible, you include a prototype in your design work. Nothing is more frustrating than doing a design simply by reading some code that you’ll be enhancing and writing a design document on the changes you’ll make. Then, when you go to implement it, you find out in the first twenty minutes that you picked the wrong code to modify. You would have actually figured this out quite easily if you had actually tried to add the code in the first place. Then, you’d have found all of the other classes that are affected by this change when you couldn’t compile it. If you decide to do a prototype, step back periodically and take a critical look at what you’re producing. Do your interfaces look clean? Are the classes designed logically? Have you already started writing spaghetti code and you’ve only been working on it for a day? Prototypes need not be long exercises. Even getting started on writing the code can get you involved in learning what useful pieces of code already exist, what needs to be modified, and how to best add the new functionality.
Even though you’ve started with a design for your code, let’s add this – never stop designing your code. Even as you near the end of your coding, you should think about whether your design was optimal. You may not want to change it at any particular moment, especially due to time constraints, but maybe you can document your suggested improvements for implementation at another time. Put Down the Keyboard and Step Away From the Code! As your release date gets closer, you’ll likely be pushing to fix all of the bugs in the system. If you’re not using a bug tracking system – and you should be – then you’ll probably be using a common spreadsheet or some other method. All of the bugs in your system should be rated according to their severity and desirability to be fixed before release.
It’s unfortunate, but your software is probably going to ship with some known bugs in it, simply because it needs to get out the door on time. However, just because you have a bug doesn’t mean it should be fixed. First of all, bug fixing time shouldn’t just be a free-for-all. Developers are more likely to spend time fixing the “low-hanging fruit.” These are the easy bugs to fix or the ones in the developer’s own code that they find most embarrassing. You may wish to let them have some time to do that, but then you should really concentrate on the most important bugs – the ones that crash the system and block functionality from working. Towards the very end of the release, only specific bugs should even be permitted to have fixes. This will prevent the “fix one bug, create two more” syndrome from keeping your release from shipping.
Managing this time well gives you the opportunity to truly control the quality of the software you send out and when it gets sent. Dominance and Submission One of the things a couple of companies did was to use submission documents. When you checked in your code, you filled in a simple form with information about what the code was for, what files and versions were involved, and what bugs you (may have) fixed. This document was checked into the source control system and emailed to your colleagues. Although writing these was somewhat tedious, they were very helpful in seeing what files went together as a bug fix or new code submission. If the build broke or a new bug crept into the system, you might be able to spot what happened by reading through some of these documents. They were also very helpful in tracking who was doing what. Several people would read these after returning from vacation to see what had been going on while they were away. Another benefit was that simply reviewing your submission documents for the week made it easy to write your weekly status report.
These documents were referenced in the bug tracking database and the comments for the files that were checked in. This allowed for easy cross-referencing. If you knew the bug, the file(s), or the submission document, you could trace any desired information from there.
|