The 10x software development gap
blog.contino.io
blog.contino.io
It's essentially a Darwinian selection process for bad developers.
If you are at a place with sane management, though, don't be in a great hurry to leave...
What is the equivalent in management? Does it exist?
Management is very different from engineering because there is no objective right or wrong, it is all subjective and all about the feelings of the people around you. Management is essentially a babysitting exercise. If you keep your people from throwing tantrums, having meltdowns, and going against the grain, you succeeded, and if you didn't, you failed.
Peer criticism is thus inherently orthogonal to management because very few people can maturely handle even a mild quantity of criticism. Keeping colleagues and superiors in a good emotional state is even more important for career development than executing your job description in a non-disastrous way.
Directing a business is much different from management, even if some management is required, but even then it's difficult to pinpoint cause and effect because there are so many externalities.
You'd think this would mean that good people who can deftly juggle a ton of variables are attracted to such positions, but in practice it seems that people who are bad at things and depend on having many ambiguous potential causes to diffuse fault over take them instead.
That's definitely the case in management; people who are incapable fall into those positions because their performance can't be definitely measured.
Because management is about managing employee feelings, whenever an objection is raised, Bob can say "Well, Alice and Dan were having a really serious issue, which I can't discuss with peers due to confidentiality concerns, and we really had to dedicate a lot of effort to defusing that and retaining them in order to keep our mindshare and minimize legal risk". That's a legitimate managerial effort. Unless you're also in a position to intimately know the issue with Alice and Dan (and if you are then why does this manager exist?), you can't really say "That was an incorrect way to solve the issue."
Human emotions create a drag on productivity, can't get around that. A manager's job is to minimize, defuse, and de-escalate that drag. You can sort of say "Bob, your team always has the most problems, you clearly can't keep them under control", but it really depends on a lot of variables, and unlike software engineering, you can't directly quantify the impact of most actions/tradeoffs. It's very non-scientific.
If you know of a management culture that facilitates this kind of peer feedback, please let me know. My personal experience is that successful management types are extremely emotionally aware and well-polished, and know that providing criticism to anyone only serves to generate hostility. They will try to manage their reports indirectly, attempting to curb behaviors and get results without having to directly criticize.
We must not become overly committed to a company, because a company is only as good as its people, and people come in and out all the time.
I'd rank technical challenges well behind culture and domain understanding as reasons software projects fail
It makes me uneasy when everybody's answer is exactly the same and they arrived it not through individual opinions but by adapting to whatever was set in place. This isn't bad if all options were thoroughly explored or possible pitfalls addressed (there are no absolute, only subjective and relative truths that come with pros & cons which each decision)....but when there won't even be a debate or conversation asking if what we are choosing to use is really the right thing because we thought it through independently or just because some big name at big company X declared it is the new paradigm.
After all, we are all fallible, development and tools we use is influenced more by marketing than proper cost/benefit analysis. Whatever seems hip, new, cool tends to triumph.
"What? PHP is sooo 2006, we need a React/Redux app for our blog so it will be easy to scale using node.js asynchronity"
https://en.wikipedia.org/wiki/Groupthink
What you're describing doesn't have any obvious "out" group in it. I think instead what you're describing is what you'd expect to see in an environment where judging the merits of tools or processes is very hard and requires a lot of experience, which may be lacking. In such an environment it's natural to look to very successful companies and just copy whatever they're doing, even if you don't fully understand it, in the hope that it works out. And sometimes it will.
This isn't helped by the massive expansion of the developer workforce over the past decades, the fact that experienced people tend to get promoted up into management where they lose touch with coding and become 'architects' working entirely in the abstract, the fact that it's almost impossible for firms to correctly match team sizes to the amount of work required resulting in frequent periods of either overload or boredom (that then leads to reinvention of the wheel simply to find something interesting to do).
And yes, finally, fashion plays way too large a role in things these days. If I had a dollar for every time I read a blog post along the lines of "we had entirely generic serving problem X and we had to pick between Rust, Node or Go", with the far older and more mature .NET/Java stacks not just discarded but entirely unconsidered, I'd be a rich guy. We end up locked in a vicious circle that works against maturity of tools and processes:
- Profitable but slow enterprises look at startups, envy their ability to get things done and wonder if it's because of the stodgy old tools/processes they use.
- Fast but money-bleeding startups look at enterprises and say "we aren't a stuffy enterprise shop so we'll do whatever cool thing I read about on hacker news the other day" and often end up boxing themselves into a corner with immature tools or business approaches. Eventually they (might) turn into big slow companies themselves, often entailing either a rewrite along the way to use more traditional tools or absurd investments into digging themselves out of technical debt (Facebook's PHP runtime efforts being a case in point)
You are totally spot on in that mature stacks don't even make the list. Obviously, new developers are going to be exposed to the new and hip fashion trends while veterans prefer predictability and stability.
It keeps me awake at night thinking about who is right. It could be that we are on the eve of a new paradigm where JS dominates the enterprise or we could be seeing another blip on the radar.
I do however think that AWS is a definite paradigm shift in how developers work, especially as serverless is gaining momentum but this is more of a devops/serverops shift imo.
However if, for example, you have a complex site with intermittent performance problems, good luck. This applies whether you are running complex async code in node.js and you're trying to track down the badly coded callback that blocks everything else. It also applies if you have multiple microservices and you're trying to track down which back end service is causing front end requests to be painfully slow 1% of the time.
And, of course, I'm waiting for Javascript to have something like the problems that Rails did in 2013 when it was discovered that automatic deserialization of requests allowed remote code execution..in multiple ways. In the case of Rails, you just had to get an updated package. In the case of npm, however, the dependency system means that you won't be able to eliminate the bug without updating the whole toolchain in a way that is very, very hard to do. The problem is that in Javascript, libraries A and B can and often do import different versions of library C. If C has a critical bug, then you can't get rid of it until you've upgraded all three. Now imagine this with hundreds of dependencies, each of which has pinned its dependencies and has not been tested with breaking changes in underlying libraries that they depend on...
Every widely used stack eventually has an "upgrade the world" fire drill. That fire drill is going to be very, very messy with Javascript.
http://idlewords.com/talks/website_obesity.htm#heavyclouds
Javascript is a mess. Node got traction because it enabled lots of web devs to port their skills to the server side without having to learn new languages. Heck, the web is a mess. We desperately need a better app platform.
Strong engineering orgs hire managers who could do and have done most of what their team does. Most TPMs at G, for example, have CS degrees.
Non-technical managers have the organizational leverage to undo any amount of design & planning that skilled people underneath them set up. It's the brain equivalent of having ADHD -- your executive control shuts down and that sabotages long-term goals.
If you've never lived through this, watch the beginning season 3 of silicon valley where their new CEO wants them to 'just build a box' and gets angry when the conversation gets any more specific than that. (If you have lived through this, don't watch it -- it's too real).
Edit: Agree that technical managers are best suited to evaluate the level of design and planning.
If you're a good programmer, you can optimize for various different things- getting something done quickly, writing pretty code, making the boss happy, following every last implied detail of spec, or, importantly, making the software as useful as possible. What you need is for an engineer to be able to think, "well, bossman won't necessarily like it and it will take another ten minutes, but I should write this in this specific way because I predict it will prevent some problems if this code gets reused in certain contexts." There are innumerable small things engineers can do solve problems that might happen, but no salary can incentivize them to do this (or even to look for the opportunities to do so) since there's effectively no way to tell if they're doing it- engineers who don't care will likely be optimizing for making their bosses happy, so engineers who do care will even often seem worse according to any effectiveness metric the company employs. And if your employees don't care, you quickly accumulate technical debt that weighs down the company, even if everyone is happy and productive.
I don't particularly think there's a solution to this. A sad fact about industrial economies is that a whole lot of boring things that no one cares about need to get done. Even most of the applications that are exciting now will be boring in the future (someday, internet search will be an old-hat, commoditized field everyone takes for granted, and Google will fall.) Maybe someday company lifecycles will just be considered a fact of nature, and everyone will simply expect the next Microsoft to roll over and expire when its flagship product becomes irrelevant; it might make things more sane.
Do the simple thing and if you're wrong then you have less work to throw away.
The systems at very large public companies drive this behavior out of employees. (They value standardization and defending the existing business too much)
That's not to say existing management structures are optimal. A big part of what the latest breed of tech giants has done is really optimize the culture to be able to get the best out of large teams of engineers, who themselves are force multipliers via code. The computers are essentially like perfectly obedient slave labor.
In the old days you always needed a lot of man power, so the biggest organizations were all about rigid command and control structures and policies that would enable a large organization to function. Sometimes these organizations were defacto distributed systems with multi-month latencies (eg. The British Empire). Under that environment it's just not viable for individuals to question procedures on a regular basis or the whole thing breaks down.
What companies like Facebook have done is come up with an organizational architecture that can use the perfect labor of computers to break through to a level of impact that could not be achieved by a human-powered organizations. There's probably still an upper limit to efficiency, but it's orders of magnitude higher given the right engineering leverage and culture.
Yes - I've seen this too. The bigger the company, the longer you have to be there to understand all the far flung parts.
I think we give managers and executives too much credit. The employees on the ground often know much better what's really going on.
Said another way, if executives have it right and employees have it wrong, the organization structure is broken.
Sorry if this is tangential, but the way the British empire managed it was by devolving almost all decision making and power to the people running the colonies. Like tax, law, culture, religion, language etc. Foreign policy was the only area where the crown called the shots.
The result was a very loosely coupled, very flexible, and adaptable distributed system, where one part would look and act competently differently to another part (I.e. Canada vs India).
If engagement manifests as pushback, then measure pushback. If employees are only working according to spec, then product ownership is effectively centralized with management - instead, increase engineering ownership, back it up by budgeting time for engineering to work on their 20% ideas for the platform, and stackrank the results if needed (big if) by giving bonuses to the most engaged engineers and considering terminating the engineers who won't engage (considering being the operative word here, many perfectly OK reasons why an engineer won't engage which aren't grounds for pushing him out of the team), which would open up spots on the team for engineers who might engage.
It's really kind of sad reading HN comments on how "oh it must be the fault of all those crappy engineers." We've all met those people who couldn't FizzBuzz their way out of a paper bag, but among the rest, most suffer from poor management. The solution to poor management is not running after mythical rock stars, it's better management.
I think the reason is that we have large customers who expect a certain level of service. So even a trivial fix needs to be properly tested, documented, packaged. Also, we don't have a really good insight into how our customers use our software. We don't know what things we can break or deprecate, so we have to be extra careful. Support calls from users cost additional money, and we want to avoid those.
Companies that do not have external customers, but write software only for their internal use (or have cloud platform), such as Facebook, Amazon or Google, do not face these problems. They know who their customers are (guys from the other cubicle), what features they use. The can take a risk of deploying an improperly tested feature.
So yeah, they have an advantage. Whether this advantage will translate to the only internal software development model surviving in the future remains to be seen.
Or eventually they do as internally everything starts to rely on everything else and they can't move fast enough when competition arrives.
I'd argue that almost nobody really knows that. [1] It's just that many developers / companies somehow get away with not being extra careful. How many libraries introduce some "unimportant" backwards incompatible change without bumping their major version number?
[1] ... unless you have a web application and really good statistics. But then, you end up being a large company like GitHub or Amazon, I guess.
When you have a platform for internal use only (or a platform that is available free of charge without any warranties), you can decide to make a change by fiat.
We would like to "move fast and break things", but our customers unfortunately don't appreciate that sentiment.
So developers should develop some kind of taste to distinguish between "real" changes and "cosmetic" changes.
"We need to be careful because customers use our software" is a pretty lame excuse. Every company needs to properly test, document, package their software. Some companies do it better than others.
It's not a lame excuse, unfortunately, there is a very real barrier of trust when you talk to a coworker (even from another group) and when you talk to a customer. At the very least, you can agree on a common schedule.
IMHO it's not a coincidence that the blog listed those companies as more "nimble".
Facebook, Google, etc, are somewhat beholden to end users, but not in a way that impedes them from rolling out what they want, when they want to.
Your contact at "big mega corp" that pays for your software may have no ability to change their internal policy that they've stuck with IE6 for years after it was sunset. So, if you want the sale or renewal, you have to support it.
There is a tension here between efficiency and privacy. Inside a corporation with an "open" culture, you can be a lot more transparent and efficient since you don't have the same privacy issues.
Open source projects can sometimes do similar things, for example with the Linux policy of having device drivers in-tree.
Also, Facebook has a history of breaking things for 3rd developers. You can't really do this with enterprise customers who pay a lot of money for your stuff.
The view that people who build and sell products can go faster and have less stress than people who write code for other people is nonsense. The pressures basically are the same; they're just from different groups of people.
I made updates to some of my code security reasons that ended up speeding things up a little bit (smaller binary to load + less reliance on permanent storage). This caused other developer's code to crash because he inadvertently needed my code to run slow under certain conditions (it wasn't obvious that the issue was a speed thing).
I'm assuming it's usually related to things using multiple threads or at the boundaries of different programs communicating?
It happens quite often when developing concurrent software.
We worked around this by having separate release channels, one for our enterprisey customers who opposed all change, and one for our customers who just wanted the coolest things first and were willing to accept some rough edges and lack of documentation.
That doesn't work if _all_ your customers are risk-averse, of course.
You must be kidding.
Selling into the enterprise space can be very different. There even a single dropped or bogus query can have a big impact on the business. They are paying, so they get to decide if and when they upgrade. You have a small number of very important customers, instead of a billion unimportant customers, so losing one because you didn't meet their bizarre requirement is a big deal, whereas in the consumer space if you decide your app is iOS only, OK, no problem, you can still be successful.
In a non-software company, this is not my experience at all.
While some end-users are local, all communication must route through distorting managerial layers. Huge swaths of features exist from fearful inertia.
That's the first sentence, hence the premise of the article. Don't you need to provide some supporting evidence for those figures?
Experience, again, suggests not. The digital leaders themselves are behemoths! Facebook has 1.19 billion active monthly users. Keeping them happy is quite a task, yet they manage to innovate alongside keeping the lights on. So how come enterprises are still so slow? Why do their technological efforts always seem to cost much more than they should? Why does the software development gap persist?
Does not follow. Facebook has lots of users but they have a relatively small workforce compared to traditional big companies. Over some threshold it's probably easier to "satisfy" lots of users via network effects than it is to please a small but critical community, anyway, but that's just conjecture.
The article is a continued series of unsupported assertions and "facts".
Then again my division was the direct heir to Tommy Flowers group and at the time had more engineers than Google had employees.
My observation from when I worked at Google was that the organisation was rapidly slowing down over time, and projects that were essentially pointless or duplicative were multiplying. Very simple tasks were starting to become extremely hard work. Much like a traditional large enterprise, in fact.
Look at how Microsoft stalled for a lot of years but after a change of culture (and focus!) they had a monster year and are poised for more. Their talent makeup wasn't that different during the bad or good times. Also, the argument fails when you look at all of the failed projects, spin outs and copy cat business of FB and Google and Microsoft. If they are 10x better in their very core, why all the failures? Because it is so easy to get wrong. Lots of companies have no choice but to do what their customers pay them to do or go out of business. Lots of companies don't have the cash cows of web search or Office to allow for huge mistakes.
Then, the conclusion is "skills and talent lie at the heart of this issue".
That's not been my experience. There's usually plenty of skill and talent at mainstream enterprise organisations. It's other barriers: cultural, organizational, funding, etc, that keep the talent hamstrung.
Even if it were true, it has less to do with talent than with organization. Legacy organizations typically have legacy customers on legacy contracts that dictate legacy development models. Just try to be agile or do continuous deployment with a typical government contract. It can't be done.
But the really sad thing is: Startups in the financial sector suck even more. Mt. Gox is just one of the many screw-ups there.
- I was never able to get email search in outlook enabled on my computer. It was a "security risk".
- Every Monday, my Visual Studio install broke and I'd have to call support in Bangalore to reinstall it.
- Our "make" system's subtasks would segfault every 1/3 times so I always ran it 3 times, sometimes 4.
- The only way to commit code (after using an out of date CVS) was to use this second in-house utility manually on every commit revision on every file. The asshole who wrote that thing made MD.
- Our 32bit system would run out of memory and take hours to compile because Java talked to C# talked to C++ talked to Slang talked to javascript all in the same address space.
I did some work for a startup that required me to integrate with an external API. The API had a bug that the service provider didn't fix despite many requests over a period of about 6 months. We had to switch to a different provider and reimplement a lot of code using a their API instead. So, yes.
And because our customers know us as being agile, there's a huge double standard to all of it. We can request changes, or even write all the code for them and send it, but won't see it live for 3-12 months. Even for critical bugs. However, when they request anything for our services, features require like a 1 month deadline from conception to deployment, and critical bugs is something like 72 hours.
A little ranty because 2016 for me was more like 90% "dealing with enterprise", 10% freedom. Thankfully next month I'm being switched to a team dealing more with internal services, so there's a lot less BS (because my boss says he's noticed how stressed it has made me, so that's nice).
Indeed. It's possible to waste huge amounts of time simply trying to decide what to do and communicating with all the 'stakeholders'. If you want to change the way your organisation builds software products you have to change the organisation.
We've been experiencing a lot of entropy where I'm at. Everyone could feel it, no one could understand it. I started looking for what might be happening and what might fix it. I came across Lex Sisney and Organizational Physics. It makes a lot of sense, at least to me.
P.S. I'm not affiliated with Lex. (Link to his Kindle book on Amazon: http://amzn.to/2iUh09B or find a lot of what's covered in his book on his website for free: http://organizationalphysics.com )
90% of the article is about our theory that large enterprise organisations have a huge gulf when compared to digital leaders, and analysing why they are in this place.
To break out of it, they need to do things in a completely different way, more focussed on building their own capability than outsourcing work.
Why does a fortune 50 company need to do that? What is the ROI on such effort? What are their risks if their IT operation is not as cutting edge as Amazon's? Those are the core questions, which your article does not even mention.
Legacy technology is another issue I don't feel you fully addressed. For example, there are many companies that start new projects using legacy technology, or the wrong technology, again for political reasons. I've seen reasoning like "We're a Microsoft shop," and "It's easy to hire Ruby developers," as the main drivers of technology choice, rather than a thoughtful consideration of the requirements of a project, and what technologies are best suited to solve the problem at hand.
I appreciate the time and effort you put in to communicating your ideas, and do not mean to diminish from that at all. I do think if you added a little more meat and citations to your arguments, and got rid of some of the sales-pitching at the end, you could strengthen your article quite a bit though.
A good tech blog post would show how you're unique, how you're innovating, and how you're making real change for your customers (with stats to back it up).
I suggest thinking about a blogging strategy with at least 1-2 posts / month in 2017. Take a few hours to plan out what you're trying to achieve and who your audience will be... Clients? Potential sales / tech hires? Being a thought-leader? Think about what you want to communicate to them that's more personal than a brochure. That's the fundamentals of a good tech biz blog at your stage of blogging.
Can we get some better stock images?
The 10X developer concept is a bit flawed. If only because computer scientists and students understand that a linear co-efficient is borderline meaningless in measuring algorithmic performance, it seems to pander to the less-technically-literate side of the engineering pool.
Another problem - the developer who accomplishes tenfold productivity of his peers in one environment might be absolutely uncompetitive in another. For example, what's the difference between tuning performance in a critical backend path and building a fully functioning UI? A developer who is ten-times better at one might be incapable of completing the other.
Instead, especially with the whole full-stack movement, wouldn't it be better to look at qualifications, ability to learn, motivation, interest and attitude? Even looking for a "ninja developer" might be better if it means someone with an attitude to hack things together at any request. And looking for a seasoned developer might be better for maintaining and rebuilding one of those hacked-together platforms.
What's the difference between a 10X and X^2/10 developer? It's time for hirers and SE bloggers to see X, log X, X log X, and X^2 developers, who are all out there.
But I think that a 10x developer is one who knows all the ins and outs of the tools in his or her belt.
Who will prefer a 10-year-old framework that served him well over an opportunity to procrastinate by means of reinventing the wheel. (I'm looking at you, JavaScript-land)
And who doesn't fall into the "tower of babel"-trap, which is the believe that there's a universal language and a perfect way of writing a program or structuring a system.
Well, there's jQuery, which is still fine for very small things (an animation here, an AJAX call there), but is totally inadequate if you need to build a rich UI of the kind commonly expected now. You'll spend less time learning something like React or Vue and implementing things in it than you'd spend fighting with the callback hell and manually crafted state machines.
There are a gazillion very useful Java-libraries out there.
I just implemented a ListView with complex filtering, live text-matching and sorting for an Android/React-native-app which has no problem displaying 100.000 items or more using Java-libraries.
React-Native's implementation on the other hand seems to be riddled with problems, judging from the bug-tracker and the confused API.
Until then I use 10+ year old tech to get work done.
Most people will agree that "some people are a lot more effective than other people". But if you take the members of a team aside individually and ask them to rank the effectiveness of their colleagues, do you get compatible answers? Has anyone ever tried getting team A to look at the anonymised commits of team B for evaluation?
Yes. As a general rule, everyone knows who's doing the work.
Usually, even the manager knows. (Whether he cares and tries to keep the productive guys is another topic)
This concept was never meant to be precise. It just expresses that some people's productivity is hard for others to understand and hard to duplicate.
It doesn't matter how many "barely can write a CRUD page" people you task to write your distributed cloud filesystem, it won't work.
(Before someone complains, because I know you, Internet, these classifications aren't permanent. I was "barely capable of writing a CRUD page" at one point, too. But you have to work with the developers that you have today, not what they could be in 20 years.)
[...]
> "So what’s the solution? To reduce the software delivery gap, mainstream enterprises need to raise their game by transforming their own internal capability."
[...]
> "We founded Contino so that we could instead transform through delivery."
[...]
> "Benjamin Wootton is the Co-Founder and CTO, EMEA of Contino."
Of course it's partly marketing but it doesn't detract from the argument.
google and facebook also have mountains of technical debt and they don't necessarily fix it. in particular some google projects i have had to build have had the absolute worst kinds of dependencies and requirements to build - from what i've heard from the inside they don't suffer so much from this because they build elaborate systems to deal with it... that is not paying back technical debt, it is creating the risk of more in the future to avoid having to pay it at all.
aside from google some facebook projects i've seen also contain the very worst of practices of the kind that invariably result in technical debt and difficult maintenance work... but i know nothing about what they do
maybe it has the same effect, and maybe that is part of the trick, that its more productive to live with technical debt if you do it right than it is to pay it back
>> Why are digital leaders (Facebook, Google, Amazon and friends) ten times better at rapidly delivering software than mainstream enterprise organizations?
Let's work our way through it.
It starts with a claim that there is a 10x gap between software leaders and the rest. Where does that figure come from? Is there any data backing it up? If you dig in you'll find that the figure dates back to some poorly researched studies in the 1970s and originally was about individual software developers. There isn't any backing to this as a figure for organizations as a whole.
Next we have a reference to the innovator's dilemma that completely gets Clayton Christensen's thesis wrong. His actual thesis is that companies are very, very good at adopting improvements that they see as necessary to improving their core competency. What companies are bad at is jumping on inferior (by the measures their current market uses) technologies that are about to destroy that market. He offers lots of examples and his follow up book, The Innovator's Solution, walks through the internal organizational reasons for WHY it is so hard.
It is well worth understanding this thesis. However it has absolutely nothing to do with building a better website.
The too big to innovate section had no flaws that I see.
The technological legacy and technical debt section comes closer to the mark - then misses it entirely. The truth is that any organization has a culture, core strengths, and core weaknesses that are part of the corporate DNA. These matter and are very, very hard to change. These will determine what organizations are good at. "Digital natives" don't simply win by not having to spend on maintenance - my experience is that their ratio of maintenance work to new development isn't different than anyone else's. They win by having cultures, processes and decision making that work better for software. Cultural elements like not trying to use schedule pressure to motivate developers, processes that try to surface potential problems as quickly as possible, and decision making that works hard to avoid a blame based culture.
Unfortunately you would learn none of that from this section. You would learn more about actual core organizational problems from http://funnyshit.com.au/the_plan.html and http://www.tamingdata.com/wp-content/uploads/2010/07/tree-sw.... (Both of these highlight very, very real problems. The Plan illustrates the consequences of information traveling through an organization where each hears what they got in line with the bias that they want, then communicates upwards the best sounding thing that fits their understanding. It takes serious discipline to counteract this. And the project management cartoon demonstrates exactly how each role tends to fail.)
Skills and talent would have been an excellent place to raise some of these points. Would have been. Opportunity missed. Instead we get trite comments about how talent perceives big companies, with no useful information on why they are that way or what would be required to change.
Next, outsourcing. As a US based developer I like calls to reduce outsourcing, but this one is sadly just wrong. All of the big "digital natives" have outsourcing as a component of their development, and make it work. The actual tradeoff is that outsourcing adds delays and creates cultural challenges, but makes for cheaper development. Proactively address the challenges, outsource things where development speed is not a priority, and outsourcing is a very viable piece of your development. It should be part of the puzzle for any large company.
And finally we come to their proposed solution. But if the real problems are not understood, then there is no reason to believe that the solution will work. In reality I would expect that the high performing team will come in, perform its project well, generate resentment, get no traction, and never figure out how the surrounding organization is sabotaging itself.
And now I'm going to need to read some Steve McConnell to get the bad taste of this article out of my system.
Your software sucks because you don't have enough technical talent. + sales pitch to develop technical talent at your company.
Hopefully it doesn't detract from the point that it is a massive gulf between a Netflix and a traditional enterprise, which runs deep into their DNA.
The big boys simply have to overcome this over the next few years.
However there needs to be an intent by the "enterprise" to achieve some end goal, which is aligned with their overall business strategy, to operate their IT more like the agile technical rockstar companies.
Such transformation is costly and disruptive, so all of this has to be properly vetted in the context of their overall strategy.