Ben Collins-Sussman on programmer insecurity:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/06/dont-go-dark.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/06/dont-go-dark.html
At one project I was more or less ordered to go dark, because it had been started despite objections from some of the developers. The result was “sprung” after it was shown to produce much better output than the old code, and resulted in a bit of a shift in the way code was produced in the team. Releasing the code during development in this case could have lead to objections like wasting time on something they “knew” wouldn’t work, and might have doomed it altogether. In the real world, ugly as it is, politics are also important.
I was told something invaluable in my first year of university, that the IT world was a very lonely place when you’re on your own, so networking and communication is the most important part of your professional life.
Due to the work we do I think it’s natural for people to lose their touch when it comes to basic communication with work colleagues. I’ve worked with a number of developers that occasionally wouldn’t even turn up to meetings because they wanted to stay downstairs and carry on working.
" I always liked the book, “One Minute Manager” for its simple but effective analogy for creating a successful working relationship. Although, I think it was written before stock options which assumes only one motivating factor.
http://www.scribd.com/doc/335040/The-One-Minute-Manager "
Although I thought the story line was a bit cheesy, it all makes sense and reminds me in some ways of ‘transformational leadership’ (http://en.wikipedia.org/wiki/Transformational_leadership). I’ve bookmarked it and I’ll be keeping it in mind when I’m put in charge of people.
Just because code is open source doesn’t mean it will be reviewed.
Code reviewers themselves have just as big of a responsibility and in the open-source community they rarely take it seriously.
Remember a few years back when Linux released their daily build and the ports/socket code snagged credit card info and dished it out to a Russian server? Not a single “code reviewer” found it but after over a 1000 installs people started wondering what all that traffic was in their log files.
If you can post a link to this story I think it would be great. Google seems to have been able to completely remove it from their index. I don’t blame them, it was bad timing because Google was touting their inexpensive Linux server farms and others were pushing hard to have the Federal Government go open-source for “security” reasons. Whoops!
Very useful article, it made me re-think my previous decision. I have started my first open source project (a really small one). I created the project on sourceforge without even having a plan and then started coding.
Haven’t had alot of time to work on it though so I don’t like that I made it public from start. For the next project I was going to “complete” it before open sourcing it. This post made me re-think that and think that it might not be so bad to start from scratch even though alot of mistakes will be visible.
This reminds me of the various talks/articles I’ve read about distributed source code management tools. One of the arguments that proponents of Git/Mercurial/BitKeeper continually bring up is that by making branching and merging cheap, you discourage the practice of ‘going dark’ and working in your own sandbox (which isn’t under source code management) and then having a nightmare of a merge at the end of it to try and integrate it into the main trunk without obliterating all the changes done since you started your implementation.
I must admit, I’ve never really worked on a big project, so I’m not really qualified to argue the pros and cons of distributed versus centralised SCM. Is there anyone around who can contrast the two approaches, and what impact they have on your working habits etc?
I actually think Git might enable people to go dark. One of the flaws with SVN is its centralized, however that means that everyone has to check their changes into the same codebase.
Git is still the best scm out there, but if an organization switches to it, the team needs to be extremely disciplined about integrating their code back to the shared repositories on a regular basis. 1 weeks of coding alone can equal 2 weeks of integration nightmares.
“Rather than think of programming as an inherently social activity, most coders seem to treat it as an arena for personal heroics, and will do anything to protect that myth. They’re fine with sharing code, as long as they present themselves as infallible, it seems. Maybe it’s just human nature.”
No, it’s the gigantic ego of “teh coder”.
How does this happen in the commercial world? Aren’t there design and progress meetings? Code reviews? Friday brown bags? Hallway meetings? Project manager stopping by occasionally? Customer meetings? Customer progress demonstrations? Arguments in the bathroom? Peer pressure?
I guess I don’t understand how an organization, large or small allows someone to go dark. I think it must be more to do with how managers encourage or discourage communication and how the group handles dissent. It does make me wonder…
I think the situation is exacerbated by the community itself: we praise, and constantly look for, perfection. We admire the mighty developer who is able to bend space and time, crafting flawless code along the way. Why do you guys think code reviews are so despised? Because we, in our megalomaniacal minds, find the prospect of having our code dissected in front of our peers simply dreadful. We just don’t want to go through them. “How could I be wrong? Are they crazy!? Impossible!”
As many of you have mentioned (or implied) already, I think we should detach our egos from our code. I know it’s not an easy task. But, we’d all be much better of if we did. There’s always room for improvements and continuous learning. As someone much wiser than me said once, the name eludes me now, “Don’t look for perfection. Look for excellence”.
Great topic. I am actually guilty of that: I code-bombed the Subtext project with a port of their blogging engine to MySQL:
http://www.angryhacker.com/blog/archive/2008/03/30/subtext-port-to-mysql—take-2.aspx
But i did keep the group informed, more or less. There were reasons that I did not work within the confines of the process, mostly having to do with time, but next time around I’ll definitely work with the group.
“Remember a few years back when Linux released their daily build and the ports/socket code snagged credit card info and dished it out to a Russian server?”
Uh, no Mr. Linux Hack, I don’t. I’m also not sure what you mean by “Linux released their daily build” but whatever. Care to elucidate?
Interesting post. Waiting to release your code due to insecurity appears to be very common. A lot of us are guilty of this, as another commenter stated. I think what I find troubling is that code a developer spent time on without releasing can lead to management decisions that have already been made, hence making the developer’s time wasted and therefore the code useless.
It’s as always: communication is the most important aspect of every project, open source or not. Providing code is a very nice form of communication, because it exactly describes what you were thinking. A big blob of code hides this communication effort and makes it less effective. Communicate early, communicate often.
Another beast: continuous integration. How to cope with the changes your teammates are doing while you are ‘in the dark’? You keep synchronizing your local tree more than you’d want to. With a fast-moving project, it sucks all your valuable coding time to just keep up with all changes.
Share your code with your team mates, really.
What’s to say? My own heart is riddled with insecurities. I see my code as part engineering, part artform. On the one hand I acknowledge that, while I’m a good programmer, there’s a lot that could be improved by being HOT (honest, open and transparent). On the other, I’m in my garret, high above the rabble in the streets below, sweating, and weeping, over my latest work. I’m guilty, many times over, of going dark. Journeying into the light can be a frightening thought. I’m working in the light at the moment, but the temptation to drift back into the twilight and then into the darkness is always there.
Another positive side effect of using Agile is that the client cannot go dark. Preventing the client from going dark is just as critical as preventing other developers from going dark. Showcasing implemented features, and recalibrating them and the requirements in modest increments is critical to delivering software, but we all knew that already… Right?
But who plays the role of the client for open source projects?
One problem is that others will laugh about your code.
They will laugh how crappy it is.
This has happened with PHP for example.
That post was worth a thousand UML documents of a Monopoly game in advancing the notion that people should, well, you know, talk to each other.
Good post.
I’ve been in a bit of the opposite situation.
I was working on a major reworking of a part of an open source program, I did try to make frequent commits of my changes to a branch, I didn’t go dark. But nobody wanted to inspect my code, look for oddidites in design, bad implementation or whatever. “Oh no, I don’t understand that part”, “You’re probably doing fine”, “Just get it done and into the main trunk”. I could barely get anyone else to discuss details about the work I was doing.
I could just as well have gone dark, it wouldn’t have made a difference.
I ended up merging my branch into trunk a bit early, but it turned out fine and it’s quite mature by now.