I’ve got some thoughts, ideas, and mantras on best practices for your dev shop. These practices will skew towards larger dev shops inside of big corporations but can also be applied to 1-2 man teams. These thoughts are inspired by a combination of The Pragmatic Programmer and The Joel Test. I read both of these sources early in my career and they have continuously provided inspiration on what kinds of practices highly effective dev team should follow. Furthermore I’ve found it surprising how many shops I’ve worked with that break these practices. Following these practices will increase your dev team’s effectiveness, making for happy developers and manager. Breaking these practices will result in a slower development velocity and frustrated developers and managers.
Streamline your local build process.
Do you think your build process is pretty fast? It could be faster. If it takes more than a few seconds to redeploy your code you lose your train of thought – and there is a cost to putting that train back on the rails. As someone who has spent a lot of time doing Enterprise Java development, it often amazes me what developers will put up with in their build processes. Here are a couple of tips to decrease build time:
-
- Your environment probably supports some sort of hot swap method where you don’t need to do a full build after every change. Java’s JVM Hot Swap feature allows this for some cases. I’ve also heard very good things about JRebel.
- If you have a medium to large sized application, you probably don’t need to rebuild the whole thing all of the time. Make sure you’re not rebuilding more components than necessary. Here are some kinds of things I’ve seen automatically included in a full build that could be excluded from a “fast” version of your build: code generated from wsdl/xsd, database migrations, unit test suite execution, minification/obsfucation of js/css. In Java, the war/ear step will package all of your files into a war/ear. When you deploy that war/ear to your application server it will unpackage all of the files. You can eliminate a step by just copying your war/ear directory directly into your application server.
Use a debugger.
Do you test your application by inserting new log statements and redeploying? Stop it! One of the best ways to cut down on redeploy time is to not have to redeploy. Every single commercially used language supports debugging. Here are a few links to get you started using a debugger with your language
Automate your QA builds and minimize QA downtime
Your QA build process should be quick and painless. I would shoot for a combination of automated QA builds (2 or more times per day) and one-click, on-demand deployments. The outage to a QA environment needs to be small – 5 minutes or less – to keep the deployments painless enough to not disrupt the workflow of the QA staff.
Doing frequent, automatic QA builds does a couple of great things for your IT organization- it sets a precedent that your team has the ability to quickly turn around fixes. It also minimizes the impact of bugs in your QA process; After all, if your team finds a bug, it’s not a huge deal since the bug might be resolved in a few hours.
Contrast this approach with an organization I recently worked with that only did two QA builds per week because their build process took so painfully long to complete. Every bug became a news headline. The management team would often choose not to fix bugs because of the huge turnaround time and the risk of additional lost time in case a bug fix was not successful.
Treat database schema updates like source control
SQL is code, and your database structure is the product of that code. In the same way that every developer working on a project needs to be able to run the software on their local system, those developers also need to be able to run their own copies of the database. Database changes should be part of your normal build process, and like your code, your database schema needs a version so you know which changes have been applied. This helps keep your development, test, and production environments all in a sane state.
It’s easy to fall into the trap where a database is very difficult to create so you end up running one development database for all of your developers to share. The problem comes when you need to support multiple work streams at the same time – this means you need to simultaneously run multiple versions of the schema at the same time. You can work around this problem by adding more schemas and more hardware, but the overhead involved may make it really difficult for developers to do the kind of risk taking and rapid iteration required to reach a high velocity.
I recommend using flyway or liquibase to manage database changes for most technology stacks. Rails has built in support with Active Record Migrations.
That’s all for now. Please send feedback in the comments if this post has helped provide value for your team, or even if it seems too rudimentary. I’d be happy to do a deeper dive on any one of these topics if there is interest.