25th Mar 2008 by Mark Turansky
No one should work alone. Ever.
Filed under Engineering No one should work alone; not in design or planning or coding or any other aspect of software development. Why?
Nobody gets it right the first time. Nobody.
Moreover, different people have difference experience. I’d be foolish to think I could write something as good as someone who’s already done it. You cut down on rework issues but tapping into others’ experience. You get it closer to right the first time by having others help think through the issues surrounding a design, and often by watching over your shoulder as you write code. Even then, no one gets it exactly right the first time, but you won’t be nearly as far off as you would be by yourself.
Xtreme Programming advocates pair programming on all production code. Not all code needs to be written by a pair, in my opinion; most is just fine for a single programmer, but that programmer should never be coding in isolation. Everyone on my team is involved with 100% of the project. We all know everything that is going on and we can jump in at any spot. Any non-trivial code is discussed by the entire team so that we can understand the best path to take. Not only does this help find flaws earlier in the process, it also gives all team members a keen understanding of the entire project.
Two separate incidences came up today that drove the point home for me.
First, a co-worker and I were profiling a piece of slow production code. We found a bottleneck and discussed a solution. His original fix would have worked, but it wasn’t as elegant as another piece of code I was able to point to that faced a similar problem and had an elegant solution. We only came to the right solution because we were working together on the same problem.
Later, another teammate discussed a Spring classloading issue with me (It was a tricky issue surrounding the generation of classes in Hibernate in Spring and having more than one instance of this in the same classloader). He and another coder came up with a solution that would have worked around their problem, but I was able to talk about an experience I had nearly two years ago where I was asked to find and fix a disastrous memory leak in our production servers. Both issues involved class generation in Spring and Hibernate, and I was able to set them on a new path. They are going to tease apart the distinct pieces of software from the monolithic whole and deploy them as separate components on our message bus. All our components are deployed in isolated classloaders, which will solve their problem.
The older issue involved the constant instantiation/initialization of a Spring ApplicationContext, where each instance caused the generation of Spring proxy classes and Hibernate DOAs. Classes once loaded are never unloaded from a JVM. This was our memory leak. The issue manifested itself at login, and our QA department did not login thousands of times a day like our users do. Code complete doesn’t mean you’re done. You’ve got abuse your system to find bugs like this.
I can’t begin to count the number of times I’ve asked for help with the design of a tricky piece of code only to find I was going about it entirely the wrong way. Oftentimes, people with a fresh pair of eyes will see things differently than you do. This does, of course, require egoless programming and smart teammates. If don’t have either, well, you’re project has bigger problems than we can solve here.
Doesn’t all this review and pair programming and constant communication decrease productivity? I’d argue no. In fact, as an investment of time, it’s paying rich dividends in decreased maintenance costs, robust production deployments, and higher morale during a time when other projects are struggling to pay off their design debt. We’re swimming when most others are just trying to tread water.
I’ve done the solo thing. I’ve also lead or been part of smart teams with tight communication. Pair programming is always the natural result of open communication and egoless programming as the team works together.
I know which one I prefer. How about you?
What's next?
Leave a comment
Digg it
Save This Page
[…] Lou wrote an interesting post today onHere’s a quick excerptTwo separate incidences came up today that drove the point home for me. First, a co-worker and I were profiling a piece of slow production code. We found a bottleneck and discussed a solution. His original fix would have worked, … […]
Mark, are you able to talk in any more depth about the ApplicationContext memory leak problem? This sounds like it might pertain to a problem I’m seeing. Was this a case of leaking classes and filling up perm space?
Cheers,
-Mike Nygard
Michael,
You are exactly right. We did not keep a single instance (static or otherwise) of the Spring AppContext. We created a new one on each login. Every AppContext generates classes (Spring proxies and Hibernate DAOs). It is these classes that fill up perm space because they never get unloaded.
Mark
P.S.
We’re using JRockit in our environment, so there is no perm space. Classes are loaded in heap space, so we simply filled up the entire heap. JRockit won’t crash with an OutOfMemoryError like Sun’s runtime will. JRockit appears to want to GC to find space and page what it can to disk. So, our servers never quite crashed, they just spiked to 100% CPU usage (GC) and lit up the drives with IO (paging), which makes the server unusable. I’d rather they just crash with an error.
Sun’s JRE has perm space that would fill up with classes. HotSpot will also throw an OutOfMemoryError before jettisoning the heap and classloaders before trying to start again. The restart never seems to work, of course, because all the required lifecycle methods are not called on various containers. I’d rather they just crash with an error, too.
For me, as I have grown as a programmer, the best things I have written, have been those where I was ‘uncompromisingly’ able to follow my own design. Granted, after years of practice, I tend to be more disciplined in keeping my code abstract and clean then most people, but that is driven by my understanding how much time is saved by not letting the code get messy. When I worked with other programmers, even with the best of them, I find I have to make compromises to keep them engaged in the development. That’s good for process, but not always good for elegance. A good solid vision is always best when it comes from a single person, if that person really knows what they are doing.
Of course, after nearly twenty years, when I do hit some algorithmic or structuring problem that is new (which gets rarer as you get older), I generally go in search of a ’sounding board’ to bounce ideas off of. What sounds great in your head, doesn’t alway look so good when you have to try and explain it to someone else.
So, I guess I’d prefer to work alone, or possibly clone myself. If only I had the 100 years necessary to be able to do that …
Paul.
Mark,
Thanks for the added info. This sounds like a promising avenue to explore.
Cheers,
-Mike Nygard
In large team systems that have multiple application layers sometimes alone is the only thing possible. The example below is a real project:
1) 10 developers were asked to get the legacy billing system integrated with a new CRM application.
2) 9 of the developers could write the code in C++ and Java that was required for integrating the CRM app to the legacy billing system via IBM MQ series.
3) 1 of the developers was from the legacy billing system written in Mainframe cobol
So that leaves 1 developer able to write, develop, and architect his code. His code came out perfectly fine and he actually beat the java/C++ developers to the release schedule. The project turned out well in the end, however what you fail to remember is not everyone is writing their code in Java or C++. Many companies have millions of lines of code out there written in languages that you may not be familiar with (and do not have the time to learn during a project cycle).
I understand your argument but it is not always doable. You still need Strong programmers that can work alone.
I guess I agree with just about everything except the title.
In both of the incidents you described, it seems like you discussed a solution with someone else, and you personally came up with the better solution because the issues echoed previous experiences you’d had.
If you’d been solving those problems by yourself, it might have taken slightly longer (without the benefit of someone else to organize your ideas with in discussion?), but you would have come up with the same solutions; it was your personal experience that was the key. If you hadn’t been there to help, your colleagues would have deployed their less ideal but probably still effective solutions… unless while implementing them they too stumbled into the better answer. Either way, the project moves on.
Not all projects can afford multiple lead developers (some will just have one lead and some interns…). Not everyone thinks better while interacting with other people (personally, I definitely benefit from discussion, but I think far deeper when alone — and that’s when my “breakthroughs” are, even if the germ was planted from a good discussion or something I read).
I’d agree that the benefits of direct collaboration are large; but never *ever* work alone with no exceptions? Too far, and just plain unlikely.
Besides, we are constantly interacting less directly — even a project I develop entirely solo will involve ongoing interaction with the customer or public, with everyone who’s published sample implementations, code for frameworks and APIs, language guides, etc. that I might read — everything I run into normally.
Despite the one-sided-ness (unintentional, I’m sure) of your examples that Rob W points out, I agree with you completely. Anyone who thinks they know it all or are ‘more disciplined in keeping my code abstract and clean then most people’ or have some other excuse that exempts this from this rule is just fooling themselves. Pair programming is one way to do it, code review is another; at my office no production code gets checked in without going through code review, meaning at least one (and possibly a half dozen!) people have peered at your changes and at least made an attempt at constructive criticism. I’d never go back to working any other way.
I agree with PJ (and Mark) about the “never” part. If you can never get better solutions from working with others then that means that you are smarter than all the rest of the team/employees put together. If that’s where you find yourself, then you need to leave quickly!
If you are the smartest person in the place, either in truth or in your perception, then you are probably going to fall behind your peers who work in other organizations where they can work with talented professionals, have their ideas challenged, and improve through collaboration.
I have been fortunate throughout my career to work with very good software developers, architects, and problem solvers. While I think that I have been able to bring a lot to the table over the last 15 years, I believe that the best ideas and solutions have come through a collaborative process.
So, I don’t think Mark is saying that you cannot come up with solutions when working by yourself. It’s more to the point that you will typically get better solutions when working with others.
Bubba