Earlier quoted context omitted.
I don't think greater risk accounts for all the slowness of big companies. Some (probably most) of it is simply breakage caused by their large size.
The major factor at work is simply a lack of personal responsibility towards the end product in a large company. In a startup there's noone to blame but you, and thus no need for politics. As anyone who has worked in middle management or above in a large company can tell you half of the job is making sure you can always find someone else to blame, while taking credit for the successes of others.
The other half of "Artists Ship"
71–80 of 132 posts
Re: The other half of "Artists Ship"
#72i love the last paragraph of that post Paul. so true.
Re: The other half of "Artists Ship"
#73Earlier quoted context omitted.
It's not abnormal. In rails I have deployed to a customer in 12 hours, starting from scratch. I was using my own framework though. In gwt, I have done this in ~24 hours. These weren't simple apps either, not just scaffolding, but had complex user interfaces.
I wasn't referring to task difficulty, just the extreme time delay between when something is ready and when it is put into production.
The delay is between when it's first claimed finished by the author(s) and when it's agreed to be ready by everyone involved. After that it can be deployed instantly...
I guess it would be possible to note in a bug tracking app "we would have deployed here" and then see how many, and what kind of bugs were found between then and actual deployment, which checks found them, and whether any of those were rollback-causers.
That would give an estimate of how much good the checks did in each case, and a way to choose which checks are ineffective for their cost. (Ish - some checks may only trigger once, ever, to be priceless).
Re: The other half of "Artists Ship"
#74This is what I call "playing defense" instead of "playing offense". By nature, the people at large companies are more concerned with risk aversion than innovation. This is also how managers like to "hold power" over the real innovators by controlling the change management process. What makes a manager more qualified to deploy to production than the programmer?
Their higher up position gives them [the potential for] a better view.
Re: The other half of "Artists Ship"
#75Checks have a cost, for sure.
What about Eric Reis's split-testing axiom?
If in a startup the developer/coder is basically the customer of the enterprise because the cost of the check is paid by the rising frustration of the coder, then should split-testing be looked upon as a check?
Even if it is, the idea of an available metric to backup claims of efficacy is really compelling.
Re: The other half of "Artists Ship"
#76Earlier quoted context omitted.
The major factor at work is simply a lack of personal responsibility towards the end product in a large company. In a startup there's noone to blame but you, and thus no need for politics. As anyone who has worked in middle management or above in a large company can tell you half of the job is making sure you can always find someone else to blame, while taking credit for the successes of others.
http://en.wikipedia.org/wiki/Principal-agent_problem
Exactly! I didn't know it had a name.
Re: The other half of "Artists Ship"
#77Earlier quoted context omitted.
During their executive retreats they decided to be risk seeking instead. I wonder if the problem at the recently troubled companies (AIG, Merrill, Lehman etc) was not enough checks in place or not enough power allotted to the employees who knew something was wrong.
From memory: the Excel bug that caused Moody's to give high ratings of mortgage securities (one of the probable causes of the whole mess) was known, but management decided not to fix it. So, greed can override checks and balances.
The bug wasn't in Excel. It was Moody's own fault, not Microsoft's.
Re: The other half of "Artists Ship"
#78"...not only wouldn't these guys have broken anything, they'd have gotten a lot more done." I don't think the claim that they would not have broken anything can be backed by facts. If you look at Microsoft, for instance, their programmers used to write very buggy code, but with the introduction of better processes, like their Secure Development Lifecycle, they saw a substantial improvement in code quality (as measure…
I meant these particular guys.
Re: The other half of "Artists Ship"
#79Some things that PG didn't make explicit: web applications can have an extraordinarily tight feedback loop between customer and coder. Multiple revisions per day are easy, especially if any single user's data is rather low-value. Many a startup of this kind has zoomed past its corporate competitors simply by iterating faster. If your product is embedded firmware for a home security device, this strategy is just not a…
Some things that PG didn't make explicit: web applications can have an extraordinarily tight feedback loop between customer and coder. He has made that point in other essays.
[deleted]
Re: The other half of "Artists Ship"
#80Yes, startups make their job better than big companies. But I think that it is a part of a more general rule: people work productively in OPEN systems, and the open systems themselves encourage working hard. Open source projects are developed more rapidly, because it is hard to imagine the system which is more open. Both users and developers control the system, and every user can become a developer. In startups we have a limited number of people who can control the process of development, but they still controll it. In other words, the system is open for founders and employees. Big companies work unefficiently because they are too closed, and a great number of checks is only a part of it.