You see, certain developers love building the first versions or prototyping — they are the ones who love hacking things together to get something working quickly. They love (and are best at) building version 1 of a product. The other type of developers love building the second version. They see their code as a craft and write unit tests for everything. "Test coverage" and "beautiful code" are phrases they use a lot.
Hmm... I find myself on both sides, though I prefer the second option by far. "Beautiful code" is indeed one phrase I use a lot :)
And of course this definition isn't black and white — there are people who fall on different sides of the line at different times, so it is more like a spectrum.
Right. And then Management insists on moving forward with v1, because they want to save the time that v2 takes, and/or continue to evolve while v2 catches up, which makes it impossible to catch up to a moving target.
If v1 wasn't successful enough to generate funding for v2, it worked exactly as intended: It proved that investing in more engineering in v1 was't necessary.
For those who are more familiar than I with the Lean Startup mentality: I've been wondering, does Lean Startup (or even Agile) inherit from The Mythical Man-Month consciously or unconsciously? As in, was this mentality developed with an understanding that a now 40-year-old study/book explains a lot of these concepts, or did it arrive at the same conclusions separately?
This article, as with many, seems to be rediscovering a pilot system. There are even shades of second-system effect concerns.
Management will inevitably and naturally gravitate towards full supporting v1 and only maybe half support v2.
Initially v1 is better because it is here and it works.
Later on, when v1 becomes a bigger mess with just a few critical additions, v2 will be worse because: v1 was supposed to have the faster development rate, right? Now we can't afford v2.
Management's initial love for v1's speed of delivery will make it impossible for v2 to actually deliver anything useful (with comparison to v1's current feature set.)
I find this v1/v2 idea ridiculous. I also find the idea of v1 programmers vs v2 programmers too apologetic. There are cowboy coders who write spaghetti code and are damaging to well functioning teams. And then there are real professionals with varying degrees of meticulousness. But real pros always end up defending and building v2 software.
That doesn't mean spike experiments and prototypes are bad. It is just that you don't present them to a management who's likely to try to promote them to production status. Good management would recognize prototypes as prototypes and demand production quality code for production.
I guess my point is; there are no v1 or v2 programmers, there are v1 or v2 companies/managers.
Fire Mary. Communicate reasonable constraints with Melissa and stay out of her way. She doesn't need your mentoring.
What happens is that v1 goes into production and any attempts to get v2 out will be met with "but the customer already paid for v1!" Then you're stuck maintaining that pile of crap which could be hell or "job security" depending on how much of a cynical bastard you are.
11 comments
[ 2.7 ms ] story [ 36.5 ms ] threadHmm... I find myself on both sides, though I prefer the second option by far. "Beautiful code" is indeed one phrase I use a lot :)
And of course this definition isn't black and white — there are people who fall on different sides of the line at different times, so it is more like a spectrum.
;)
This article, as with many, seems to be rediscovering a pilot system. There are even shades of second-system effect concerns.
Initially v1 is better because it is here and it works.
Later on, when v1 becomes a bigger mess with just a few critical additions, v2 will be worse because: v1 was supposed to have the faster development rate, right? Now we can't afford v2.
Management's initial love for v1's speed of delivery will make it impossible for v2 to actually deliver anything useful (with comparison to v1's current feature set.)
I find this v1/v2 idea ridiculous. I also find the idea of v1 programmers vs v2 programmers too apologetic. There are cowboy coders who write spaghetti code and are damaging to well functioning teams. And then there are real professionals with varying degrees of meticulousness. But real pros always end up defending and building v2 software.
That doesn't mean spike experiments and prototypes are bad. It is just that you don't present them to a management who's likely to try to promote them to production status. Good management would recognize prototypes as prototypes and demand production quality code for production.
I guess my point is; there are no v1 or v2 programmers, there are v1 or v2 companies/managers.
Fire Mary. Communicate reasonable constraints with Melissa and stay out of her way. She doesn't need your mentoring.