Jakub is a Java EE developer since 2005 and occasionally a project manager, working currently with Iterate AS. He's highly interested in developer productivity (and tools like Maven and AOP/AspectJ), web frameworks, Java portals, testing and performance and works a lot with IBM technologies. A native to Czech Republic, he lives now in Oslo, Norway. Jakub is a DZone MVB and is not an employee of DZone and has posted 128 posts at DZone. You can read more from them at their website. View Full User Profile

Fast Code To Production Cycle Matters: For Pleasure, Productivity, Profit

01.08.2013
| 1652 views |
  • submit to reddit

I spent one afternoon adding a much needed feature to our application. Now I have been waiting for several days for various people to review and approve it. And I have just realized how tiring it is and how much energy it takes from me.

To create something and get it out into production at once (plus minus) is fun and really motivates me to do and try stuff, it is a great feeling to see it immediately affecting the users and processes. And a quick feedback (from the users and the behavior of the application) – while still being engaged for the thing and having all the context in my mind – makes it easy and fun to fix and improve it, leading to a better result faster. Waiting, on the other hand, is exhausting and depressing. I usually start working on something else, forget the context, lose the interest (it is not easy to be fired up for two things at the same time) etc.

Therefore, if you care for happy developers and better products, make sure that your time from code to production is as short as possible. Look at your process, eliminate all delays, make it smooth.

PS: I am not saying that code reviews are bad. They are great. They just shouldn’t be a source of delay. For example if you can pair-program then you get an instant code review.

Published at DZone with permission of Jakub Holý, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)