As I’ve been reading through “The Art of Agile Development” (from O’Reilly, by James Shore & Shane Warden) there’s been a whole load of great suggestions for development practices and not all of them are restricted to an “Agile Only kind of world. One of the major ones that’s stuck in my head (and is repeated quite a bit in the book) is the idea of being “done done” in your development.

The average PHP developer seems to say they’re “done” when the code works from their simple testing, usually just entering values to ensure that things work correctly. I hate to break it to them, but this shouldn’t be considered done. Getting the code working correctly is only the tip of the iceberg – there’s so much more to do to get everything ready to deploy. Besides the code being complete, “done done” also means:

• Having documentation, both in the code and about the code. If future generations of developers were to come around and need to update your code, good documentation is a must. One line comments aren’t going to cut it…at the very least use something like the formatting for phpDocumentor to provide some automated docs
• Making those unit tests pass every time is essential. (You do unit test, don’t you?) Writing tests for all the bits and pieces of your application may be a pain, but it can save you in the long run. Imagine being able to fire off a test suite and being confident that those changes you just made haven’t broken anything.
• The code has to work in the build for your project. Some projects are small enough to where they don’t really need a build, but if your project is much more than a simple site with a database backend, you could benefit from a build[1]. Developers should be able to do local builds to check their work prior to a commit and push.
• I must fulfill what the customer wants in the update or new feature. Sometimes, it just happens – you get to writing your code and you think about “this one cool feature” or “that other fun thing” that PHP makes so easy. You wonder why the customer didn’t want that in the first place. Be very careful with thinking like this, it could lead to some pretty random stuff in the end. In the end, the customer needs to be happy with what you give them – be sure it’s what they asked for (user acceptance testing).

Being “done done” means that, if you handed over your code to the testers or even the end customer, you’d be confident that it works and is ready to be integrated. Sure, it’s about the code being tested and correct, but its also about making it behave as a part of the larger whole. Your code (code ownership is a whole new can of worms) shouldn’t be viewed as “this part that does this” but more of a piece to the larger puzzle of you/your team’s application.

[1] What’s a build? A build lets you automate several things you might currently do by hand to get your code ready for production. This can include things like: building out databases, minifying code, running unit tests and checking syntax on all files to be pushed.