I've witnessed first-hand three start-ups slowed or stopped by "ninja" developers using the start-up as an excuse to try some cool new technology that will look good on a resume. In two of them, they were paid the going rate. If you're not getting paid, or getting paid a stipend, then it may be fair to use the start-up as a sort of experiment - the cool experience may be all you get out of it - but this should at least be agreed upon. However, if you're getting paid the going rate, then this is a job, not a party, and your job is to get the job done.
Lets be honest, this sort of thing goes on at large companies too for two reasons: resume stuffing, and job security code. My favorite is when someone builds some really "cool" tech that only they understand, uses it to get a new job, and then quits. If a manager lets this happen, they ought to be fired too, in my opinion.
From my experience anyone who doesn't do proper research into viable options, is always the person who wants to build "cool" amazing bleeding edge things are junior developers.
There's nothing wrong with this mentality when developing fresh new code for small projects but once you work in an established company you need to stop and think.
Is this a new language, technology?
What kind of support is available, how hard will it be to hire someone that knows this or train them up?
Do we already have something pre-existing that objectively is just as good?
Without such conservatism, you end up with undocumented frameworks that are no longer officially supported, no one knows it and there are hundreds of these things that just replicate each other, just because it was something "cool" at the time.
This applies to frameworks, languages, libraries so on.
Someone has to support these things 2, 5, 10 years even down the track.
85% of all developer time must be spent on business specific logic
Yeah. Come back in two or three years when your application's code has degenerated into an unmaintainable mess, and adding new business logic is taking four times as long as it needs to because no one sat down are rearchitected the software to meet new needs.
I've experienced two jobs where this, in effect, was exactly what happened. In both firms, previous management used short term contractors to get a "lean" proof-of-concept out the door. In both cases customers loved the product and started asking for more features. And, finally, in both cases by the time I was hired (at +3 years in one company and at +5 years at another) the product had grown so bloated and so unwieldy, management had brought development in-house and was embarking on a multi-year project to clean up and rearchitect the code so that it would accommodate new feature requests from customers. If these two companies had paid more attention to the architecture of their code, then a lot of pain could have been avoided farther down the line.
This strategy is great if you're building a pump-and-dump startup (like Instagram, or Tumblr). But for an ongoing sustainable business? It's a recipe for disaster.
The article implicitly urges one to keep "core competencies" in house. It sounds as if in these instances, the core competency - development of the software product - was outsourced.
You miss the point--you're talking about outsourcing development. The point of the article is to use libraries whereever you can, not to oursource all development to non-in-house developers. (The other reply to this gets it).
I agree with the idea of not wasting time, but if you follow the advice given here, you'll come across much like a narrow-minded idiot middle/product manager with an extremely short-term focus. Your choice.
Programmers need to grow, so it's important for there to be opportunities to try new technology. Obviously this can't frequently get in the way of the main thing, but it matters; you don't want to fall behind.
Nothing in the piece argues that one shouldn't try new technology. Under this 85%-rule-of-thumb, we went with Amazon Web Services for 100% of our infrastructure in 2008. It was clearly the right choice, and worth learning. My point was more that developers have a gravitational pull toward new and interesting that needs to be tempered by a focus on what's best for the business--and too often, it is not.
Couldn't agree more with this. The notion of an "85% rule" seems unnecessary as long as business features are being implemented regularly and by their target milestones.
The concept is sound. You increase "velocity" by strategically decreasing your development effort, but this leaves out the idea of technical debt completely. I've start to believe there are things that will kill you in the short term (bugs), medium term (missing features), and long term (architectural issues). You can play with the percentage of effort put towards each area in every version/release, but neglecting any one for too long can kill the product. It seems easier to explain the balancing act to people that way.
Does this apply to non-startups? Once one becomes an incumbent, is it not wise to minimize external access (inherent in outsourcing)? E.g., the core competency of the NSA might not be system administration, but perhaps they would now prefer that someone more imbued with their culture had performed those duties.
I think it does apply to non-startups as well, because the "outsourcing" I'm talking about with software development is really just using existing tools and frameworks, not bringing new developers into the fold.
For example, I think it makes more sense for the NSA to use existing databases than writing their own...
This one is must-read for all (not only non-technical) managers. And actually it sheds light not only on management but recruitment as well. Simply you need people who are passionate about the result (shipped feature that adds business value) not the process (exploring, tinkering, learning etc.).
[+] [-] jamieb|12 years ago|reply
Lets be honest, this sort of thing goes on at large companies too for two reasons: resume stuffing, and job security code. My favorite is when someone builds some really "cool" tech that only they understand, uses it to get a new job, and then quits. If a manager lets this happen, they ought to be fired too, in my opinion.
[+] [-] applecustard|12 years ago|reply
There's nothing wrong with this mentality when developing fresh new code for small projects but once you work in an established company you need to stop and think. Is this a new language, technology? What kind of support is available, how hard will it be to hire someone that knows this or train them up? Do we already have something pre-existing that objectively is just as good?
Without such conservatism, you end up with undocumented frameworks that are no longer officially supported, no one knows it and there are hundreds of these things that just replicate each other, just because it was something "cool" at the time.
This applies to frameworks, languages, libraries so on. Someone has to support these things 2, 5, 10 years even down the track.
[+] [-] quanticle|12 years ago|reply
Yeah. Come back in two or three years when your application's code has degenerated into an unmaintainable mess, and adding new business logic is taking four times as long as it needs to because no one sat down are rearchitected the software to meet new needs.
I've experienced two jobs where this, in effect, was exactly what happened. In both firms, previous management used short term contractors to get a "lean" proof-of-concept out the door. In both cases customers loved the product and started asking for more features. And, finally, in both cases by the time I was hired (at +3 years in one company and at +5 years at another) the product had grown so bloated and so unwieldy, management had brought development in-house and was embarking on a multi-year project to clean up and rearchitect the code so that it would accommodate new feature requests from customers. If these two companies had paid more attention to the architecture of their code, then a lot of pain could have been avoided farther down the line.
This strategy is great if you're building a pump-and-dump startup (like Instagram, or Tumblr). But for an ongoing sustainable business? It's a recipe for disaster.
[+] [-] thyrsus|12 years ago|reply
[+] [-] joeemison|12 years ago|reply
[+] [-] joeldidit|12 years ago|reply
Programmers need to grow, so it's important for there to be opportunities to try new technology. Obviously this can't frequently get in the way of the main thing, but it matters; you don't want to fall behind.
[+] [-] joeemison|12 years ago|reply
[+] [-] chourobin|12 years ago|reply
[+] [-] jared314|12 years ago|reply
[+] [-] thyrsus|12 years ago|reply
[+] [-] joeemison|12 years ago|reply
For example, I think it makes more sense for the NSA to use existing databases than writing their own...
[+] [-] ArekDymalski|12 years ago|reply
[+] [-] dschiptsov|12 years ago|reply
btw, is it possible somehow to reduce the amount of nonsense^W links from medium.com? We have enough narcissism here from patio11 and likes.)
[+] [-] ArekDymalski|12 years ago|reply