Two weeks seems a bit much, but once you have a significant client base of paying customers, you simply must have some form of production control and QA. Even good developers make mistakes, and letting everyone just push their changes to prod over lunch is a recipe for pissed off clients.
The other half of "Artists Ship"
121–130 of 132 posts
Re: The other half of "Artists Ship"
#122Nice writeup on half an idea. Now, time for some release engineering. How do you give good coders free (enough) reign while keeping tabs on the stupidities of the lesser ones?
In a startup, it's acceptable for service to be accidentally down for short periods while the geniuses running the show fix their latest cockup. In large companies, it isn't. How do you get the best of both worlds?
It is not by removing all safety interlocks. Sysadmins, especially good ones, can tell you in excruciating detail why not. Most programmers are not very good sysadmins, or at least not as good as they might like to believe. Coincidence?
Re: The other half of "Artists Ship"
#123" And you know what? It would have been perfectly safe to let them. In fact, the acquirer would have been better off; not only wouldn't these guys have broken anything, they'd have gotten a lot more done."
My experience as a manager of a team of programmers for many years is that for sure they would love to be able to write and release w/o a QA process, they do in fact take the site down when this is allowed!
Re: The other half of "Artists Ship"
#124Very nice - I think another reason why companies overpay - is because they don't negotiate, they don't check out the hot companies, they allow their employees to make decisions and most have never hired a company - so they go with the best name so they can say they hired them - it looks good on their resume - companies don't realize that most executives - director level and above are doing nothing more than building their resume - and their projects go unchecked, unaudited and bascially the company gets screwed - and frankly it is the company's own fault. Once a company loses it's founding partners, the transition team runs wild with all the changes they want to make and not looking for those things that made the company successful - spending is at all time high, brand suffers because the new team is too busy spending that they lose sight of what is important - the customer - gosh does that sound like AIG?
Re: The other half of "Artists Ship"
#125As a previous startup coder who was acquired by a much larger company, I can truly say you've hit the nail on the head. I never minded working 70 hour weeks before, but now I have a hard time punching the clock 35 hours a week. I hate my new higher paying job.
Re: The other half of "Artists Ship"
#126My experience is that extensive procedure comes because the small company start up approach doesn't scale to large companies. Every one I have worked at that has transitioned from from 10s to 1000s of people was failing because it tried to continue as if it was 10 wizards at it. The wizardy actually hindered others because it was opaque to them.
Interestingly the biggest company I worked for actually ran the best because perhaps its roots being 80+ years before any of the others would allow the significant difference to be tracked.
Re: The other half of "Artists Ship"
#127Another interesting read. I'd like to note that (while it wasn't the focus of the essay), many of the expensive "checks" aren't there for monetary reasons, but rather human safety and the dire consequences of a poor decision.
Working at Motorola on cell phone code could be a great way to give everyone in the modern world a cool new feature - or accidentally break 20+% of all phones out there. A terrible Mickey Mouse movie could destroy a brand. Take it a step further to NASA, vehicle engine design (and safety), oil pipelining and refining, etc. and the cost could be human lives.
That said, I'm very interested in the cost of these "checks" on those industries. Not monetary costs (although important), but rather the cost in stifled future innovation.
Thoughts?
Re: The other half of "Artists Ship"
#128In fact, the acquirer would have been better off; not only wouldn't these guys have broken anything, they'd have gotten a lot more done.
That's where you lost me. Sure, there are companies who add checks without thinking of the consequences, but as a company goes from a startup that is not making money to a more mature company that is making money, the cost of breaking things becomes very, very high. That is why most post-startup companies add more checks, to protect their revenue stream. And any company making decent money has a revenue stream that far outweighs the amount of money that the programmers would be willing to pay to have a faster release cycle. And the risk of the company losing their revenue stream for any significant amount of time far outweighs the risk in losing decent programmers because they aren't happy with the length of the release cycle.
You seem to say that these particular programmers would never have broken anything, but I find that impossible to believe unless they are working on something that is not at all complex or is inconsequential to the revenue stream. Every programmer, even the best programmer in the world writes code with bugs in it. The more complex a system is, the more likely there are to be bugs in it and as a company grows and makes money, the more complex their systems will become.
As an example, let's say that you were responsible for a web application that brought in a million dollars of revenue a day and you had these supposedly perfect programmers that never made mistakes who were responsible for the code. Would you let them just throw out whatever code they wanted onto the servers because you trusted them to not make mistakes? Or would you be more reasonable and put some checks in place first to make sure that the application worked correctly?
Obviously there needs to be a sane balance between the risk of breaking the application and the opportunity cost of not updating the application and the frustration of slowing down development is one of the costs that should be weighed, but to say that there shouldn't be any checks added as a company matures is almost laughable.
Re: The other half of "Artists Ship"
#129When I was an automotive engineer the industry instituted a Japanese "check" called Design Failure Mode Effects Analysis. For every component the engineers would have to predict the ways the design could fail in testing and what steps would have to be taken to fix them. Time spent doing DFMA's added significantly to the cost of producing a new part and worked counter to weight optimization. Do you think, twenty years of DFMA's later, that automotive design is more efficient?
Re: The other half of "Artists Ship"
#130Thanks for this article Paul. Now i really know the why behind the what i observed working for a big company
http://computinglife.wordpress.com/2008/11/14/hands-free-or-...