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.<p>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.<p>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?<p>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.<p>This applies to frameworks, languages, libraries so on.
Someone has to support these things 2, 5, 10 years even down the track.
<i>85% of all developer time must be spent on business specific logic</i><p>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.<p>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.<p>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.
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.<p>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.
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.
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.).
Is all that pathetic flow of long-words about the old idea of having a secretary?)<p>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.)