Just finished reading Part I: Laying the foundation of Code Complete by Steve McConnel. This is my second attempt to read it all and I hope this time I’ll finish it. I have read this part before, though it was a good time freshen up my memory since it’s about preparations for the development. I just got back from my vacation and I had a list of new projects which I should start working on so I found it useful.
Even though it’s for software developers, I’ve found it relevant to my work as a web developer. The main idea of this part is that software development is not only writing code and debugging it. A significant part of time should be spent on requirements, architecture, construction planning, making a detailed design, etc., before even writing a single line of code. Of course, this adds up hours to your original estimates. Yet, this could and probably would be a time saver in the long run. It requires you to analyse and consider a lot of things, raises questions for you and your client. Thus it could save you from accidentally building the wrong thing. The book contains a lot more reasoning and even proposes a few solutions how to handle your management about the extra hours. Another useful part.
The most difficult part for me seems to be detailed design. I’ve tried creating a detailed design for a small project I had to do this week. Eventually ended up doing something different than originally planned. Meaning different architecture, classes and methods. It seems that the design I’ve put out was not as detailed as I thought it was, so the first issue was that I did not spend enough time on it. Second thing is lack of experience, since it was the second time I had anything to do with Silex framework. Lack of experience forces you to do design decisions during the coding. Unfortunately those design decisions are usually not conscious and well thought. I guess the only way to get better at it is by simply doing it and learning from your mistakes. They accumulate experience and help you become a better developer. Writing a journal and tracking those mistakes (or good practices) would be even more helpful.
Another great thing about the book is that the author dedicated a whole chapter to metaphors for a richer understanding of software development. Some of those metaphors might help you to persuade your client (or your management) to do things the way they should be done.
I do realize that the points I’m making are very abstract, though the book has so much information that the list of key points for this first part would be longer than my post. It’s hard to remember everything you read, so that is why the boos is of “handbook” category. Get it and keep it on your work desk for future reference :-)