Since many years I have been writing down the guidelines I use when developing software. Mainly because it’s easy to forget some of them, but also because at times you need to explicitly ponder their weight in a trade-off between two or more “principles”. One thing is clear after all those years I have spent writing and reading software, whether it was written by me or someone else: writing good software and writing good code is difficult.
Michael Foord has written up his “30 best practices for software development and testing“, and it’s hard to disagree with his list: there is a lot of good advice in it! If you’re just starting to code, you can’t hope to apply all 30 “rules” at once. The only gripe I have is with the title of his post: in my view, it should have been published as “30 best practices of software coding and testing“. There is, after all, a lot more to software development than coding.
Let me prove that statement. For heaps of excellent advice on the subject of software development in general I always pick up Alan M. Davis’s “201 principles of software development“.
My copy was printed in 1995, and it seems there are no reprints – which is a shame, because Alan Davis did a great job of consolidating proven principles in categories ranging from requirements analysis over design to coding and testing and product assurance. Each principle is explained, and Davis adds at least one reference text for almost every principle. In summary, the content of this book is not very original but it remains a valid and comprehensive overview of good software engineering practices. That remains true, even after more than 20 years!
PS. I already wrote earlier posts on the subject of software engineering principles, e.g. in May 2015…
