I hadn't thought of programming this way but it rings true. Call it the "genius complex" or "hacker complex": wanting to create something great alone and in a short timeframe then "unveil" it and bask in praise from peers. Unfortunately for self-approved geniuses and hackers, great things are built incrementally.
"The Myths of Innovation" by Scott Berkun has something to say along these lines but in general terms rather than in terms of programming. Check it out:
I agree that projects are best developed and released incrementally, but I don't see that as being the same as releasing unfinished code, or code which otherwise doesn't meet the developer's own expectations of fitness.
I read the article, and he makes good points, but he was also concentrating on a specific subset of software development, and I don't think the principles apply equally well to individual projects or projects developed by small teams.
Also, it glosses over the reasons that we all developed those habits in the first place: the software development community is notoriously acerbic. Although most of the time nobody may care about your unfinished code, eventually you'll post something, somewhere, that will elicit an ugly response that could have been avoided if you'd just rolled out something a little more polished. (See also: the OpenBSD development community.)
I understand about not wanting to share code in progress. Even though there are 427 coding methodologies, each of us still wants to work in our own style. Chances are likely the someone won't understand what we're doing even if we do. If I want feedback, I'll ask when I'm ready.
Finished code. OTOH, is a totally different animal. Not wanting your code to be peer reviewed is indeed insecure, stupid, and in many commercial shops, a violation of protocol. Only a fool expects no feedback.
Junior Programmer: "I'm not sure it's right."
Mediocre Programmer: "It's not right until I say so."
Good Programmer: "It's not right until you say so."
This is something I can relate to very well - I work for a large company that out sources lots of work to India - some of the developers are good, some terrible (as they are everywhere) - but without fail they refuse to show you anything until its all done. There are at least two problems with this:
* Often they make poor implementation decisions that as the 'designer' (I hate branding myself with that term) I don't like and know it could be done a different way, but now that X weeks of development work have been done, its too late to change it.
* Reviewing a big blob of code like that is a nightmare - easier if I get drip fed it feature by feature. Also, often when reviewing code I have noticed a junior developer will use the same anti-pattern over and over again - so they have to refactor all through the code - if such an error was noticed early, it would have resulted in much less work overall.
Are they coding to a spec? If you're outsourcing you better be or you're just asking for trouble.
"Reviewing a big blob of code like that is a nightmare"
Right. That's why "big blobs of code" are never acceptable. Use whatever strategy you want: structured code, object orientation, reuseable components, etc., but use something.
The problem isn't outsourcing. And it isn't lack of incremental reviews. The problem is in standards, methodologies, and project management. You'd think a "large company" would know better.
You're give a lot of credit to large companies - things are done wrong in them more often than not.
The developers code to requirements - a bunch of signed off requirements are handed off to them and they go make the thing work, so yea there is a spec, but it doesn't go to the level of 'use library x' or feature y or a 5 table join instead of 5 individual selects etc. The developers have license to code the thing in the best way they see fit.
The point of my comment was to agree with what was said in the article in that its bad to go and spring 5 weeks of coding on the team (whether its an open source or closed source team) without running what you are doing past the other team members or stake holders at frequent intervals.
In my case, I have been sprung with weeks of code in one go - it doesn't really matter if there are modular/OO approaches being used - 5 or 6 weeks of code can run into thousands of lines.
The same problem appears with other things too - eg I need a report for 20 components of a system, and it takes some time to prepare the stats (one off manual task) for each part - I would say send me the stats for each component as you get them, but they tend to hold everything back until its all done - then when the report isn't quite right its a much bigger job to fix it than if I had seen some stuff early.
Agile development is sort of like this too - show your customer things each week as its easier to fix when its going down the wrong path, instead of springing three months of work on the customer in one go to find its no what they wanted.
> Are they coding to a spec? If you're outsourcing you better be or you're just asking for trouble.
I see these two as quite distinct. Coding to a spec, even at the level of BDD, simply means making your implementation conform to some abstract behavioral specification.
If writing code that could both adhere to such as spec and was easily maintained and extended in the future were easy, then outsourcing (or simply relying on the most junior programmers you could hire) would definitely be the only sane way to build software.
Unfortunately (or fortunately, if you are a developer who wants to work and knows your craft) it is not nearly so simple. Even a perfect functional spec is usually at least 3-4 levels of abstraction removed from the actual code needed to implement it.
More fine-grained BDD specs or unit tests may come closer to allowing for mostly mechanical translation into working code, but they also must co-evolve with the code itself.
A spec is a description of the expected behavior of the program, NOT a description of what the code will look like. Unless we have a different conception of "spec"?
If you are specifying the entire, detailed "design" upfront, you are not allowing for Hacking as a valid methodology (specifically, Bottom Up Programming). As we are discussing this on "Hacker News," I'm not sure we want to discredit Hacking as a valid model for software development.
"And it isn't lack of incremental reviews."
Aren't incremental reviews a valid part of project managemnt and software methodology?
For a couple of projects weren't particularly big, we required this set of "specs" before release (for internal use):
- Requirements specification
- Design specification
- Use cases
- Test plan
Plus some reports. The design included a functional specification, but all of these documents evolved iteratively, so as it turned out the design document was mostly an after-the-fact record of what we did. But I don't think anyone here is an avid supporter of BDUF, so what else can a team do to prevent foolish code, other than requiring everyone to show their stuff and explain themselves regularly? If your up-front specification is comprehensive enough to prevent any bad future programming decisions, you don't need a programming team to implement it, you just need a compiler for it.
Maybe that's the deep secret to "Worse is Better": bad ideas are exposed to the harsh glare of other developers early on, but it doesn't sting so bad because nobody expected perfection. Humble is better.
Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes.
I agree with this fundamental thought expressed in the post.
But sometimes making the decision of 'when' to open source your code, does also have to take in to account the 'community acceptance' factor. If the code is of not that great a quality, it can put off potential key contributors, and actually wrongly tag that product with a hard to get rid of 'below average' kind of label.
Of course, once its out, or if someone is contributing to an existing open source project, throwing 'code-bombs' isn't a great idea at all.
On the other hand, most artists like to keep their work secret untill it has reached a certain level of readiness, or am I mistaken? Unfinished paintings, books, poems...
It's a natural reaction for any creative to keep their work under wraps until it's ready, but ready is relative to the medium (and the creator).
Having worked professionally as an illustrator before becoming a programmer, I can confidently argue most illustrations don't look close to complete until you've laid down 95% of the paint. If you've worked all week on an illustration, and it doesn't meet your expectations, more often than not you need to begin with a clean canvas.
Code, on the other hand, can be functional in as little as one line. Functionality can be built upon that, and you can refactor code more often than not without destroying the functionality that relies upon it. Code is an infinitely more flexible medium.
The impulse to shelter your work from critical eyes is powerful, but "unsightly" work can be altered at the drop of a hat. Perhaps programmers need to be a little more open.
A counter example by Paul Graham from "Six Principles for Making New Things".
"Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly."
I think in our domain (software), there may be some additional rational to keeping things secret. An unpolished early revision of code may be a much better way to judge a job applicant than a resume. No one would consider publishing the rough draft of their resume.
The appropriate counter argument (IMHO), is that "unpolished" is different than "poorly written", and you generally don't want to work with managers that can't comprehend and appreciate the difference.
I'm better at realizing most of my code is shit than I am at producing great code so I'm hesitant to share because that could "promote" bad programming and people might be misled about my taste. That also means I don't need reviews that much, I'm already busy improving my skills/codebase for things I know are sucky.
I work on a small team with a large legacy codebase in ClearCase. Builds take long enough that it is easier to work on a large chunk and do a clean build once the couple of libraries and executables I'm working on are in good shape, then deliver the blob.
I check-in on my own branch on a feature-by-feature basis, but in practice, no one sees my work until a large blob is out there. There's limited opportunity to second guess people (this cycle, we had one formal code review per developer).
At my work I am just stuck with these limitations, but I don't recommend working this way.
I always felt that if I can't put my code to others' scrutiny and live with the fact that it has errors and be glad that others spent THEIR time to help ME find problems, then I am a pretty crappy programmer. After all I can't expect myself to be the omnipotent programmer who writes perfect code.
Edit: I always felt that if someone did not look at some code and find a problem with it, they just didn't look hard enough :)
I think I would feel I was making other programmers do too much of my work if I just sent them code that I new was bad, and have them waste time to look at it and just confirm that, yes, it's bad.
That's different, of course, from making your best effort and then asking someone who you think is good at programming to find all the places you could do better.
My friend's company has a policy: Everyone gets code reviews all the time by peers.
The benefit is, the reviewer gets to learn a different part of the system, and the person getting reviewed gets his code scrutinized. It is a very beneficial system.
As far as showing bad code: There is a different between delivering crap and delivering code you are satisfied with. If you are satisfied with it, thats when scrutiny is necessary. You need to get a feel for when the code is good enough, because you can spend all your life making it just a bit better. Same kind of stuff applies to artists, you just need to know when to stop improving and start letting others scrutinize the work.
I once posted allot of code from my misc directory and it was just generally useless code, some of it was just unfinished, and some of it wasn't supposed to do anything so it couldn't be finished and some of the code worked, though most of it was just some stuff i wrote as fast as i could type and not even run it later to see if it works. Like some form of instant poetic inspiration witch you might write down or record in a dictaphone on the street but not publish it in a book or even read it to your friends. I have a lot of those and i am not afraid to share them just for the fun of it. I also share my not useless code(witch isn't much). I also wrote one of my school exams in python and showed it to some friends(i think it was a biology exam or something) :D
"The Myths of Innovation" by Scott Berkun has something to say along these lines but in general terms rather than in terms of programming. Check it out:
http://www.amazon.com/Myths-Innovation-Scott-Berkun/dp/05965...