Last night I finished my latest read from O’Reiily, Code Simplicity – The Science of Software Development. I spotted the book the other day when O’Reilly was running a special on a few books and the ebook was cheap so I figured it couldn’t hurt to give it a try. After all, the “science” part in the title made it sound like there might be some hidden truths that could be applied anywhere in development. Unfortunately, most of the book just ended up being more of a rambling journey though things that most software developers that have any years of experience (even the bad ones) would already know.
The author spent a good bit of the book dedicated to definitions and explanations about various practices and ideas in development, as if he thought that maybe the audience reading the book wasn’t savvy on the topic. The first few chapters also included several sections about the book itself – why it was relevant and mentions of a “science” that never seemed to fully resolve. Granted, trying to make a “science” (more a set of laws than just best practices) out of something so varied as software development is a pretty difficult task, but I felt like the author tried a little too hard to make his case for the book and less time actually defining something that could have been interesting.
All this being said, if you don’t worry too much about him trying to propose a “science” to it all, there were some good best practices reminders in here for developers of any language:
- Don’t rewrite, rework – a reminder that, despite it seeming easier to chuck the whole system and start over with the knowledge you now have, you’d do better in the long run to change things from the inside out, a piece at a time (hint: unit tests make a world of difference here)
- Know the problem before writing the solution – listen and understand the problem before you start with even one piece of code. If you don’t fully understand the problem, you’ll end up with half-assed software that only does part of what was needed.
- Think specific, not general – if you immediately jump to the “well, if I use a plugin architecture for this part…” chances are you’ve already added too much complexity. Think small first – make it work, then make it better (I’m a big fan of iterative development)
- Use more experienced developers as a sounding board – chances are, if someone’s been in the development biz longer than you, they’ve come across your situation before. Sometimes you have to seek out that person on a specific topic, but don’t just forge ahead blindly. At the very least, try to find blog posts or articles that you can use as a guide.
- Don’t forget that time is important too – most developers (me included) easily forget that time is a factor in their development. No, I’m not talking about the actual time to write the code or the looming deadline to finish it by. I’m talking more about the time you’ll need to do research, try things out or even consult with fellow developers. Time put into something to gain knowledge is an investment too…don’t forget to remember the value of it.
There were other points made throughout the book, some more relevant than others, but I wish the author had spent less time focusing on definitions and more on expanding the sections with some more practical advice. This (relatively short) book probably could have been summed up in a small series of blog posts and been just fine.
Book: Code Simplicity – The Science of Software Development
Author: Max Kanat-Alexander
I’m a big fan of unit testing and promote it whenever I can – not only does it help create a code base that a better quality, but it also lets you keep things consistent. No more of the “cross your fingers” kind of coding. A good, well-written set of unit tests can save you a whole world of hassle in the long run. Taking it one step further, you get to TDD (test-driven development) where you write your tests before you even write your code. You start with the usual “W”s – why, where, when, how (yes, I know that last one’s an “H”s) and develop the test for those rather than looking at a current chunk of code and testing what it already does. There’s some people that swear by it, one of them being the author of this book.
I’ll try to put up another post when I get closer to the end – it’s hard to find time to sit and read these days, but just little nibbles at a time work just fine.
I’ve been working through this book for the past few days and let me just say from the get-go, this book would be any asset to pretty much anyone on the PHP development food chain. It’s not a book for programmers telling you how to survive in an enterprise environment (there’s some of that, but that’s not the focus). The book gives the reader one of the most valuable things anyone in a corporate environment can have – how it all works. It might not be 100% the same as things around your office, but Ivo does a great job of giving everyone involved in the development of web apps (and it doesn’t have to be PHP!) a better idea of how all the pieces fit together.
The flow of the book follows a typical project flow with topics like:
- Gathering requirements
- the Planning stages
- which of your Building Blocks you’ll need to get the job done
- Developing the application
- Pushing it out to the public and keeping it maintained for its users
For each, there’s lots of great tips crammed in with suggestions and recommendations based on some of his previous experiences.
There’s little to no code in the book, so don’t buy it expecting tutorials on writing code in an enterprise environment. What you will find here, though, is a better idea of where that code you’re writing will fit in the bigger picture.
Let me also reinforce that this book is not just for developers. Honestly, anyone involved with the creation of web-based applications can benefit from it. Managers, developers and testers will all find bits in here that they can pick up and hang on to for current and future projects.
I also like that he included the part there at the end about the different development methodologies. It’s a nice addition that can help open up the reader/developer’s eyes to new ways of doing things (Agile is especially fun).
I’d definitely recommend that you pick up this book if you’re going to be doing development in anything more than a one man shop. Actually, strike that – I’d recommend it for anyone that wants to get more familiar with the management side of development and how their code works in.
More information: php|architect’s Guide to Enterprise PHP Development