Programmer Insecurity
blog.red-bean.com
blog.red-bean.com
"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...
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.)
Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes.
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.
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.
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.
"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 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.
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."
* 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.
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?
- 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.
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.
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.
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 :)
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.
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.