The Skeptical Methodologist

Software, Rants and Management

Beyond the Machine Gun Nest: Thoughts on the IT workplace and a path forward

I don’t want to produce a wall of text here, but there is quite a lot to say and very little space to do it.  The space being, of course, how long this little charlatan can keep your attention before you drift back to whence you came, be it Digg or Reddit or watching the Olympics.

The machine gun nest metaphor was, make no mistake about it, inspired by the horrors of game development and application development at the big three (Apple, Microsoft and Google). In all of these companies you see the same classic pattern of competition between designers on how dedicated they can be (measured by how many hours they put in) to the product, with little to no real compensation for it. The worst of the perpetrators would be the game developers where it’s the actual process to expect 80 hour work weeks.

French Guy’s original post and it’s follow up merely reminded me of these facts and finally pushed me over the edge to the point where I felt that a counter-culture to this industrialization of software needed to form. I’m under no false pretense that one little blog entry was going to start a counter culture. But it was all I could be bothered to do 🙂

YC was just the instigator, it wasn’t the focus, of the Machine Gun Nest metaphor. And while I agree that entrepreneurship and motivating ones self to do something different is categorically different than working a corporate job 9-5 every day, and in fact, I believe such entrepreneurship should be encouraged, the same old anti-patterns of believing hours equals productivity can creep in. We’d be naive to think they couldn’t.

The problem, as much as we’d like to blame it on corporate culture, was never actually corporate culture’s fault (although they’ve certainly taken advantage of it.) The criticism was always fairly leveled at we, the designers, hackers and programmers. I said we had a frat-boy hazing mentality over who could put in the most hours. And if the problem is with software culture, then why wouldn’t it also exist at startups?

The point of this post is to not go into the specific problems that crop up again and again, so much so that they have their own acronyms like KISS and YAGNI. The point is we all know a guy who’s ten times more productive than us and gets done in half the time. That’s the image we should celebrate – not the martyr who stays up into the wee hours of the morning ultimately fixing a bug that his own fatigue introduced – but the guy who can make it seem so easy and effortless that we the point: We’re doing it completely wrong.  Locate these people and learn from them. Don’t just keep putting in the grind work thinking that you too will finally get the Zen of design and code and be able to be as productive as he (or she). The productive programmer did not get to 4 hour work days by working 12 hour work days and more than he got to five thousand lines of code to perform some functionality that could be rewritten in five hundred thousand. Why would writing more buggy code help one become the type of programmer that wrote less code over all? Indeed, since lines of code seem to be our easiest metric, it’s counter-intuitive to understand that the fewer lines of code we right, the more productive we actually are (barring obvious abuses of this system).

This is an example of advice that we should all be skeptical of. Everyone in software is selling their own methodology, their own system, their own technique, and while there is some gems in there, it’s mostly coal. Including this particular methodologist. Including Paul Graham.

I won’t claim to fully understand the inner workings of YC. I’m not vying for sponsorship nor am I really keen to get involved in their culture. But given what I know of business, I can point out a few things that – while they may be true – I find on the face of them to be unbelievable.

The average investment rate YC puts in it’s child projects is supposedly around 7%. But what does that really mean? Does that mean that, should I have an idea, pitch it to old Paulie, and get some funding, they are going to ask for their standard 7% stake in the company right then and there, and forever thereafter they will sit on the sidelines as a disinterested party?

Probably not. They will probably give me a little seed money to get started, see if I have potential. In fact, that’s what start up investing is all about – you have to feed the creation just enough for it to survive and grow, but not too much that it grows into a bubble. It’s a tricky art. YC can’t be any different.

They will provide me seed money, and the more promise and potential I come back to them with, the more they will be willing to invest in me – and the more they will ask in return. Equity stakes and investment most likely grow geometrically, meaning the 7% ‘average’ grossly underestimates what YC will eventually want in your company. At first it will be a tiny sliver of equity, and many of these start ups will fail. Then in round two we have some good ideas, so we grow our investment – providing more money and asking for more equity.  Quite a few of these startups fail too. But the cycle continues until we have one or two really good ideas, really far alone, and predominantly owned by YC.  But because there are SO FEW that make it, the mass numbers of failures and their equity rates pull down the average to something that doesn’t seem scary at all. Say 7%.

Other fields have sayings too. Economists say there is no such thing as a free lunch. A smart guy promising to turn your start up into the next Google for only 7% equity is a free lunch.

The true betrayal of YC’s intentions are no further away than the management process: build to flip. This is not at all a new idea – I know two companies, Enron and WorldCom that were definitely “built to flip”. Whether you intend to flip over the company to some potential buyer, or flip it to the public with millions of buyers of company stock, the motivations and the means are the same. Short term thinking, and the invitation of a less than honest culture.

Our “Build-to-Flip” CEO just wants to make last quarter’s earnings look as good as possible because he has options he wants to exercise.  The key phrase there is look as good, not be as good.  Looking good is a hell of a lot easier than being good. This encourages sloppy accounting, this encourages high promises, and one ground breaking news conference (with nothing to show for it) after another. Sure enough, the price goes up, the management secure their retirement, and then waltz out of the room.

Build to flip is short term thinking – its boosting last quarters earnings to make the stock go up a blip before you sell. It’s an immoral way to run a company and it leaves many others who believed in you (your shareholders) out in the cold.

I’ll bet you were thinking though, it’d be pretty sweet to be that CEO.  And I’m not screwing over a bunch of shareholders, I’d be screwing over Microsoft, who’ll be buying me up. And who likes them anyway?

That’s not the case, sadly.  Read up a few more paragraphs and remind yourself that when you are ready to flip you, the creator of the enterprise most likely will not be the prime share holder. You’ve vacated the CEO’s position and became just another shareholder. “A shareholder?” you ask. “But they’re the ones who get screwed!”

Creating value is hard, and there is no shame in putting in the hard work to create your own value and then selling that value, at a fair price, to a potential buyer. In fact, its rewarding, its proof that all your work meant something, it got you somewhere. But putting in that hard work only because your project is kept on life support by angel investors who require more equity each and every time you visit is selling your idea, your vision and your work out short.

Keep the music industry in mind. Many bands sign record deals and receive what’s tantamount to a ‘loan’ from the record company to produce a CD. They are required to use the company’s own studios, the company’s own equipment and the company’s own personnel. In fact, the usually end up paying the company back nearly all of the ‘loan’ one time over by purchasing services from them. Then, when the CD is made, the actual loan is paid back a second time in sales. The artist, generally, got left out to dry. We might see celebrities and rock stars seem to be living a fantastically wealthy life, but that’s not the majority of them, and even those that are generally are living beyond their means.

Being given seed money for equity is a loan (of potential future dividends). And it’s a good way to start a business – a tried and true way. But one must keep a watchful eye that you don’t end up producing a CD and being asked to leave because it’s taken everything you made from your start up to pay off that loan.

Enough of that. What’s the solution? How do we fix this – stop working these long hours for no reason. I admit, my last post came up suspiciously long on accusations and suspiciously short on solutions.  And this post too, will not offer any ‘solution’ per say, but perhaps a few ideas.

I’m a big fan of capitalism. And any time I see something mispriced, say, for instance, our labor, I think – well how can a market fix this?  Any true defender of the capitalist faith should find mispricing blasphemous, and need to be fixed immediately.

We must then better the market by redefining what it is we programmers sell. Frankly, we’ve done a very bad job of figuring out what our actual value added artifacts are, what someone would actually ‘buy’ from us, other than a full fledged finished product (that can never be defined up front!)

If we were to create a market – like an auction, where buyers of software and sellers of software openly bid on new functionality, new applications, new algorithms, what would it look like? We don’t all have to become freelance designers – these markets can operate inside of corporate intranets too.

If I open up a bid on this market, and it wants a piece of software – imagine with me – what will I be reading? What will you see as the semi-perfect specification that will define the contract between me, the supplier, and they, the customer?

Our craft has always benefited by breaking down problems into yet simpler parts, and certainly, I’d say, many of our ‘parts’ actually have already good specifications to them. If I bid on a contract that had me develop a class in C++, where the class interface and documentation was already given to me, and the customer simply said “make it do that”, we’d be closer to buying and selling based on value rather than hours. Our collective wisdom and experience of years, and hundreds of designers and coders all bidding on different projects, will more accurately price the difficulty of a specific problem or application than our current metrics of trying to derive SLOC counts and man-months.

What of underbidding? Just like on EBAY, our reputations will follow us around – in fact, in a much more useful way than our resumes could ever provide – and any potential customers can see our rating – “AAAAAAA!!! Would buy again!”

A simple mechanism – hell, it could even be web based – for a market of components, of classes, of function and algorithms would both solve the issue of more properly valuing a talented programmers time, and also more properly policing our craft of, shall we say, less talented individual’s contributions.

You can already see prototypes of this sort of thing on ‘rent-a-coder’ sites, but the classic web 2.0 question is: Will it scale? Could open source, for example, begin to offer bids out on patches that are known issues but no one seems to want to work on? Will compensation, then, from open source be monetary or something else? Prestige? Or just perhaps a better way to organize what needs fixing, what needs adding, and what needs ignoring?

I was inspired by this idea when reading more about ROWE or results only work environment. But it’s the problem of defining what counts as ‘results’ that needs fixing for this to work. I do not think its intractable, although some parts are harder than others. But being paid for results is a hell of a lot better than being paid for effort – and it optimizes for results, rather than effort. Say goodbye to projects that go over-budget and past schedule that we’re basically optimizing for now by focusing on effort. “Seriously guys, if we just worked a little harder, we could get this done.”
That kind of thinking could pass into antiquity.

I offer up this market/auction driven approach to the critical masses.  May it be shot down and descend in flames gloriously.


August 10, 2008 - Posted by | Software Culture | , ,

1 Comment »

  1. Part of our value add is deciding how we break large problems down. Sometimes, it’s deciding what to code, and what not to code.

    Too often, a clueless manager will ask us to do something incredibly hard – problems legions of phd’s have toiled on to no avail. Or they’ll avoid asking for something they think is hard but is actually trivial.

    We also add value as teams, coaching each other and working on each other’s strengths. These are all difficult things to quantify.

    Having tried rent-a-coder sites to outsource small jobs, I don’t think it’s worth it. We’re more than just piece workers, and our work is devalued when we focus on the details of our work.

    Comment by Daniel Haran | August 20, 2008 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: