Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The other half of "Artists Ship"

paulgraham.com

Post reply on HN
Print view View original

91–100 of 132 posts

Re: The other half of "Artists Ship"

#91

Post by Retric »

Haskell wrote: post #87
pg wrote: post #78

Earlier quoted context omitted.

I meant these particular guys.

My point still is valid. Even these particular guys certainly would have written buggy code. A QA process could correct it.

I worked without testing for 2 years and released a single bug into production. In that specific case I thought something might have been wrong but they needed it ASAP so I said who cares. My father once had a tester say "Ops I stopped testing your code over a year ago" when he released a fix to some buggy code someone else wrote which still had a few bugs. After adding a formal QA process I stopped double checking how buggy my code so I could get more done but I have ended up releasing more bugs.

So I have little respect for formal QA.

Re: The other half of "Artists Ship"

#92

Post by bootload »

tdavis wrote: post #51
bootload wrote: post #41

"... Steve Jobs's famous maxim "artists ship" works both ways. Artists aren't merely capable of shipping. They insist on it. So if you don't let people ship, you won't have any artists ..." Steve Yegge has had the unenviable luck of working on 3 products all of which have not shipped (cited as business reasons) yet he still works for Google ~ http://blog.stackoverflow.com/2008/10/podcast-25/ So it seems there is some…

I spent 3 months at the end of recent deployment furiously developing an (arguably) game-changing app for the Army's secret intranet. I knew in advance it wouldn't actually get deployed, despite everyone up to the Task Force Commander loving it and touting its importance. The day came when it was "done" (of course I had become attached and there were a million things I wanted to add) and ready to be deployed... then…

"... I worked on it because I love programming and trying new things. Everything I was doing at the time was new to me so it was fun, engaging, and a learning experience. Plus, it beat the hell out of anything else I could have been doing in that wasteland ;) ..."

Good explanation.

I put it as a question as I'm wasn't conclusively sure why people would sign on to assignments that have a probability of failure. But I've since found that smart organisations allow pursuit of training and learning as a reason to keep staff and motivation. I figure the USF know a thing or 2 about motivation. Hope your putting the lessons you learned into some hack your working on :)

Re: The other half of "Artists Ship"

#93

Post by cwp »

Whenever someone in an organization proposes to add a new check, they should have to explain not just the benefit but the cost. No matter how bad a job they did of analyzing it, this meta-check would at least remind everyone there had to be a cost, and send them looking for it.

To me that's the most important paragraph here. That takes you from "let's make sure this never happens again" to a cost-benefit analysis. The issue is not whether or not to have checks, as much of the discussion here assumes. It's about realizing that not all checks are equivalent, and using that knowledge to get the greatest safety at the lowest cost.

Re: The other half of "Artists Ship"

#94

Post by randallsquared »

tomsaffell wrote: post #56
pg wrote: post #49

Earlier quoted context omitted.

Writer are like hackers, yes. But the reason most salesmen like to work hard is that they're paid on commission. That's very different.

I suspect that what is really going on here is that workers who love their job actually prefer to work hard AND good programmers love their job . So it is probably true that good programmers actually prefer to work hard , but that is not the whole truth... Also, since most workers don't love their job , it is probably also true that good programmers are unlike many workers . To say that programmers are unlike many TY…

Yes. I've worked in fast food, and as a cashier at a convenience store, and in both cases, those who were better at the job preferred busier times ("It makes the day fly by, doncha think?").

Re: The other half of "Artists Ship"

#95

Post by jpclauss »

Paul,

Surely if the costs of checks could be "discontinuous," "non-linear," "step-change," or however else you would like to term it, then perhaps the potential cost to the company of NOT having the check in place could also be the same. Larger companies potentially have more to lose by having recurring lapses in supply, or in the ongoing case of your essay, software service. Of course, software/coding may also be a special case. Additionally, it's true that your "committee" example represents a discontinuous change in bureaucracy for that firm, which would make it much more reasonable to expect an equivalent affect on cost.

Re: The other half of "Artists Ship"

#96

Post by randallsquared »

"The purpose of the committee is presumably to ensure that the company doesn't waste money. And yet the result is that the company pays 10 times as much."

Well, only if they still buy every product, which would defeat the purpose of having a gatekeeper committee. If, instead, the committee approves only 1 in 25 products that would otherwise have been bought, the committee saves them money (leaving aside the cost of the time of the committee-members).

Re: The other half of "Artists Ship"

#97

Post by netcan »

pg wrote: post #88
gaius wrote: post #63

Earlier quoted context omitted.

Not true. Good salesmen love the power, convincing others to do their will. They are more like actors or politicians. You can't fake charisma just because you might get paid more.

You can't do anything well without liking to do it. The difference between hackers and salesmen is that hacking is what hackers like most. Salesmen who have sufficient money seem empirically to prefer playing golf, whereas hackers with money tend to keep hacking.

That doesn't change the fact that while they are working, they prefer to be getting lots of sales.

They like to get paid for it, they can even be greedy. They like to get recognition for it, that can go to far too.

But they also enjoy making the sale.

Re: The other half of "Artists Ship"

#98

Post by neilk »

tdavis wrote: post #50

Having never had a "normal" job per se (okay, I bagged groceries for a year when I was younger), I still find it hard to believe that it can take two weeks just to get something deployed. Maybe one day I'll finally truly believe all the stories I've heard -- two-week deployments, meetings about future meetings, etc. For now, some part of me still believes it's simply implausible and everyone is engaging in hyperbole.…

Sure. It is often due to dysfunction, but it can even happen to good teams.

Imagine you have to fix a simple bug, like the description of an option in an HTML page.

Imagine that: the codebase is a bajillion lines of Java or C++ that no one person truly understands any more.

Imagine that: fucking up is considered bad. Maybe you're protecting important user data, or maybe it's just code for the online store, and even an hour of downtime can wipe out the day's profits.

The team is so big that your feature is scheduled for deployment along with four or five others this week.

As usual, management has skimped on QA so there are not enough of them to go around. Also, QA was added late, so there's no fast automated test suite. It takes them a full week of manual and semi-automatic testing to go through all regressions.

After that week of testing in development is over, then it goes to staging, where it's tested with real live data and staging subsystems.

At least somewhere in this, something breaks (something is always breaking) and a fix is produced. Then the new build is tested all over again, with the basic smoke tests as well as any test suites that are applicable to that unit of code which broke.

This is causing another trainwreck because we promised feature X to client Y by end of the month. What do we do? Emergency team meeting! Let's rebalance the work schedule.

Meanwhile, your change, which just a simple HTML fix, languishes as this build goes into its second round of testing.

Oh, and did we mention that you have to have submitted your code in time for translation into six languages? I'm afraid that the French translator did not produce a satisfactory translation in time, so we're going to have to hold your change back. Can you revert this and put it in next week's build? Thanks.

Re: The other half of "Artists Ship"

#99

Post by jaytee_clone »

How about a check immunity system?

For example, competent people who knows their own weaknesses well and often check their decisions with others should be immune to checks

Good programmers often let other good programmers check their codes. Good writers often let other good writers proof read. Good managers often discuss his decisions with his employees before deploy them. They should be check immune.

You can even pass out check-immune badges to encourage non-check-immune people to be more critical of themselves :)

Of course, this system itself is a check. Who decides who will get check-immunity? What's the successful-decision-ratio threshold? I think it's possible to implement a light-weight system little cost.

Re: The other half of "Artists Ship"

#100

Post by levbor »

I'd say that the reason for bureaucracy in large organizations is that central management doesn't trust middle managers. Whereas in a startup there are a total of three bosses, and all trust each other.
Post reply on HN