A tale of two development competitions
Developer productivity pitfalls and tips
Motivation
Attending a developer contest for two consecutive years taught me most of what I know about software developer productivity. This post is the summary of the two events; the decisions, mistakes, and changes I made to the processes and what I've ultimately learned along the way.
The first year
The contest was organized by a big IT company. The primary aim was to hire the best people, but it was a fun event as they did a good job on the coordination. The rules were simple: The contestants were teams of three, and we had two days to implement a specification at the fullest possible extent. We had to use Java web technologies, and also had some constraints on the application server and the database.
The specification was quite lengthy, about 7-10 pages long. It was tedious to read, so we took a shortcut and processed it on-the-fly. It also had a sample UML on the database schema, which covered most of the needed functionality.
The first mistake was neglecting the specification at the beginning. The sample UML was also misleading; it made the impression that it's complete, but it wasn't. The most notable consequence was that we had to rewrite parts during the initial development.
Technical-wise, we also used the required softwares in an unthinking manner. We had the deployment times around 30 seconds, thanks to the oversized Java app server. Also some modification required a full restart; that lasted minutes.
We started coding right away, coded the database objects as we saw in the sample UML, then moved page by page. As a team of three, we had UI and server roles; we could work in parallel. Then dinner, some recreation, then head to sleep.
Coding continued the next day, albeit yielded little progress. We decided to keep coding even after the day was behind us, effectively skipped sleep. We were young, and we thought it won't hurt.
We halted progress during the night, and were like zombies afterwards. The state our code was at the end of the contest was much like the same it was at the end of the second day (the contest started on the afternoon, so there were two nights during the two days).
Our end product was scary. When we started coding, we thought we were three programmers, coming from the best university around, with a few years experience in the industry. We were coding two days straight, and the result was next to nothing. We had a few pages with UI, but most lacked server-side.
The scariest part of it all? We still won honorable mentions; most of the other teams were even less productive. We were glad back then to win something, but now I find it quite disappointing.
The key points where we went south:
- Neglecting the specification had us rewrite our code over and over again.
- The tools were not appropriate for rapid development. The long deploy cycles made the process tedious and sluggish.
- By skipping sleep we made bad decisions and lost the ability to concentrate and thus progress.
The second year
We went more prepared the next year. There was also a change in the team. We were there for first prize, a modern notebook.
As for the preparations, we made some choices beforehand. We used simpler technologies, like JSP instead of JSF, plain Servlets instead of a full-blown JEE stack. This resulted in more verbose code, but less pitfalls during the contest. Lowering the required brain power for a specific function is beneficial, even at the expense of more typing.
Then we revised the tools. We opted for Jetty (a more lightweight Java servlet container) and HSQLDB, an in-memory database. This allowed a very fast deploy cycle of about 3-5 secs (vs ~30 secs last year) and a clean state every time.
When we finally got the specification, we powered off the computers, seek an empty room (it was a university, so there were many), and started specifying. Everyone had to read the whole document three times before even the smallest discussion was made. Then we did a database schema and a navigation diagram. It was a mind-consuming and tiring task, which took several hours. But we had a solid foundation to start with.
After the specification round, we enjoyed some music, ate dinner and went to sleep.
The next day was the main part of our coding story.
Defining test data was the next important thing. With the absence of a persistent database, all test entities had to be recreated at startup. Providing examples for all edge cases was another key part; those we can easily test with during UI development. Using well-known characters instead of made-up ones is another nice trick. We had Gandalf, Frodo, Papa Smurf for example. It made each test case easy to visualize and argue about; it was like telling a story.
Another nice side effect of having test data is that all pages can be developed independently. Also we could minimize communication among team members, as we had a clear concept from the beginning, everyone had clear tasks.
We were super productive, slept a healthy amount both nights, while completing most of the functionality. It was quite funny waking up at the third day to see other teams coding like zombies. It reminded us how we went last year, and how futile it was.
At the end, we earned an honorable mention, same as the previous year. The reason? We could not port our app to the required database and application server in time. Sadly they discontinued the contest the next year, so we could not get our sought-after notebooks.
There are quite a few important points here:
- Simpler technology often means increased productivity. On the other hand, care should be exercised, as rejecting everything complex will have opposite effects.
- Code-to-see times are important. A few seconds is a max that is tolerable during development.
- Read the specs. Read them again. And again. Having a clear concept saves you from rewriting your code over and over again before it is even ready for 1.0.
- Have test data for each use case. It saves you a few clicks for every change, and it adds up.
- Don't underestimate the time needed to use enterprise-grade software. They are not made for productivity.
