Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

A Badge of Honor

03.16.2010
| 3919 views |
  • submit to reddit

Often times, I hear folks exclaim that they’ve been on “40 development projects over the past 10 years.” Or, “70 projects spanning a 20 year career.” They say this as if it’s some badge of honor. But I’m not so sure that it is.

Of course, there is value in widespread project exposure. Gaining experience with new technologies. Experiencing the dynamics of different teams. Understanding the challenges surrounding different organizational cultures. Each project is unique, bringing its own set of experiences, and these experiences are all incredibly valuable.

But when I see that someone has jumped from one project to another, it also leaves me wondering! Have they ever stuck around long enough on any single project to see their decisions through to the end? Have they ever had to live with the decisions they’ve made? An amazing compilation of knowledge is obtained by not only participating in the early stages of development, but also in maintaining the software system after it’s been released. To name just a few:

  • Dealing with the challenges of Phase 2, while also maintaining Phase 1.
  • Managing multiple branches of the software system. Merging those branches back together. Creating new branches.
  • A critical production issue arising about the same time you need to start heading out for that important customer demo.
  • Attempting to change a piece of code that hasn’t been touched in 10 months.
  • Watching the software system grow from nothing to a system that’s more than 500,000 lines of code. Keeping the build performant. Keeping the build working!
  • Being forced to live with seemingly meaningless early design decisions that haunt you over time.
  • Trying to upgrade versions of third party libraries while development is ongoing. Simply recognizing the right time to upgrade.

And there is so much more. Priorities tugging you in five different directions at one time. If you’ve had the luxury of living with a system (and the mistakes) you created, you’ll realize that there are very few, if any, decisions that shouldn’t be given conscious thought.

When an individual sticks with a project for a long time, they realize the importance of maintaining a clean design, a robust suite of unit tests, and how they package their software system. There is significant knowledge gained by sticking with a project for a long period of time. Perhaps the next time you hire a developer, it might be wise to ask them, “What’s the longest you’ve spent on any given project?” That may be more important than the number of projects they’ve been on.

Somewhere along the way, I picked up a small piece of advice that has helped serve as a valuable guide. There is a big difference between ten years of experience and one year of experience ten times. When you jump from project to project, never living with the decisions you’ve made, you have lost an opportunity to learn what works well and what does not.

From http://techdistrict.kirkk.com

Published at DZone with permission of its author, Kirk Knoernschild.
Tags:

Comments

Jeroen Wenting replied on Wed, 2010/03/17 - 2:20am

The reality for most people in this profession is that they're pushed from one short term project to another every few months to years. Very few hang around in the same environment long enough to see everything in the same project, but most will have seen it all at some stage in some project.
I've myself been involved in all stages of a product lifecycle from pre-analysis to post mortem (and had to carry one or two to the grave). But I've never had all of those stages happen in one and the same project (unless you count the one or two that failed to get off the ground at all, which went directly from pre-analysis to the grave).
In part that saddens me, as I've never seen something go through its entire lifecycle. In part it's a good thing as it's given me broad exposure to a variety of environments and technologies (rather than being stuck in the same narrow environment chosen by someone back in 1997 and maintained to this day with no major upgrades because those'd be too expensive and risky to implement, thus stopping my skills from growing past what I knew back then).

Anilchandra Noo... replied on Wed, 2010/03/17 - 7:25am

It may be partly true that when an individual sticks with a project for a long time they realize the importance of maintaining a clean design as in my case I worked on both Developement and maintence Projects.I feel working in maintence projects will reduce your development skills as you does not have freedom to implement new design as the system was already in the production and change should be minimal if the system has a good design than you have chance to learn something out of it initially but as the time passes it will be monotous to work and one will loose interest on the system.I prefer to have a mix of both if there is a chance to do so. and a developer cannot be judged based on the time he spent on the project even if he spent long time on a project may not have got a chance to work on the all kinds of issues araise in production.since there will be a limit of work assigned to him in the whole team.

Jeroen Wenting replied on Thu, 2010/03/18 - 1:07am

Correct. I've been working on essentially a single maintenance project for over 2 years now, and most of my time for the last 6 months at least has been spent waiting for approval for changes and almost hoping for emergency calls to the helpdesk about urgent production problems so there'd be some potentially interesting troubleshooting to be done.
Due to budget restrictions and company politics we're not allowed to do any active development of the system otherwise, and our training budget has been slashed so severely there's not even room for me to spend the time I have available in seminars or reading books so we're effectively idle.
That's little different from what I've experienced in just about any other company I've ever encountered (they all promise challenging work and lots of time and money for training and "personal development" in their recruitment procedures but once you're hired that all turns out to have been just a sales pitch.).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.