Recently I ranted about non-productive tasks that can divert focus away from the developer and seriously hamper the effectiveness in your project. As an extension of that discussion I would like to propose a new rule – the 30 second rule:
Any process that takes longer than 30 seconds to run, must be fixed.
Of course the processed included should be restricted only to things that are directly involved in the development feedback-cycle, i.e. include things like starting up a server, connecting to databases, fetching snapshot dependencies. Exclude things like install a new database, setup the the system for the first time or run *all* unit/system tests.
Can this be done? I think so. It should be doable, and the benefits should be quite obvious if you are familiar with things like being in the zone and context switches. Keeping feedback cycles below 30 seconds would significantly lower the risk for a context-switch or getting sidetracked.
Below are some example techniques we have been using internally to lower the feedback cycle time:
Unit Tests
When possible, always code against unit tests instead of the entire logic stack which usually includes HTTP requests, database calls etc.
Databases
Databases can be a time sink for a couple of reasons:
- Connection pools that eagerly initialize connections can take a while to start up
- Hibernate usually scans and verifies/updates the schema (depending on configuration)
- The application might need to fetch an initial set of data, if this is large data set then it takes time
Some database specific solutions we have used:
- No database. If there is no defined data source, then we simple disregard persistence calls (and don’t go barfing all over). For instance, when developing poker logic there is no inherent need to communicate with the persistence tier. The ability to cut this out makes setup and running the server easier.
- Use an in-memory database. If you are not depending on an initial data set or fixture then you might be able to use an in-memory database such as H2. This usually speed thing up.
Synchronous Startup
Containers usually starts things in a serialized, single threaded order (for obvious reasons). If you have some module that takes a long time due to external communication etc, then perhaps you can make that initialization asynchronous. Unless you have a really good reason why the deployment process should wait for your cache loader to go to a remote database and eagerly query for thousands of rows.
Basically any modules that opens a TCP socket to somewhere can lead to ungodly long timeout periods, if you get this often you might consider for the developer to be able to opt-out of that module or make the initialization asynchronous.
Local Maven mirrors
Make sure you have an office local maven repository that caches all the stuff your developers need. Otherwise you can bet your hat that people are sitting around waiting for the latest snapshots for a couple of minutes every day.
Decoupling
Break down your system into separate modules. If you have a monolithic design/architecture then chances are that every developer will need to start everything including the kitchen sink regardless of what aspect of the system he/she is working on.
Is the 30 second rule viable for all projects?
I don’t know. What do you think?
You can contact him at: fredrik.johansson(at)cubeia.com