I did the math today.

If I entertain 12 pre-funded startups a year, and give each 30 hours free of work, and do this every year for 10 years… I’ll have worked on 120 projects and given away in the neighborhood of $300,000 to $500,000 worth of work.

That suddenly sounds like a *lot* of risk.

It’s also about $30,000 to $50,000 worth of income per year that I’m not making. Which is a sizable chunk.

A vision of what San Francisco looks like in 2075, when Big Startup leaves SV like Big Auto (effectively) left the Rust Belt

Today I discovered that my grandfather kept a diary. Not a very big one, and not very often. Files encrypted with consumer grade encryption of the day, but the house computer cracked it easily enough.

Interesting stuff. The entries in the middle were the most interesting - he had some thoughts on Big Startup.

Big Startup. There’s a boat that sailed about 30 years ago. Taking with it half the city’s tax base, and what population that could leave. Mom and Dad felt tied to their mortgage. I talked to them about it a few years ago, and I guess when I was born people actually cared about their mortgages. Their house was only underwater by 25% when I was born, they thought they could sell and get out.

Totally different time.

I read some of Grandad’s journal entries while waiting for the bus, at the ruins of Civic Center. One of the panoramas of inside of the ruined Center has been my u-desk background picture for about a year now.

Wait, I see the bus.

Ok, back now. The driverbot didn’t like the crumbled $50 I handed him for my fare, but it’s green and registers as money all right.

Last $50 I had. I’m going to have to bum rides off Liz, or hope to not get caught anywhere after dark.

Man.

Ahh, ok, home now. Home in that technically it’s for sale for $15,000, but nobody is stupid enough to buy it in this neighborhood of foreclosures and abandons, so might as well be mine. Been here maybe a year. Fridge, plumbing, computer and net still worked, so that’s an upgrade from the old place.

I added some warning detection too. Don’t really want someone to squat my squat. Nobody expects a 30 year old Rumba to be outfitted with a webcam, a stun gun, and link to the house computer. That’s what I say anyway.

Today I did some repair work down in the Mission. One in ten items that I repaired I could keep, as payment. My backpack’s half full of antiques. Mostly crap.

Gods, when was my last actual paying job? Last year when I worked the hotdog cart at the Wharf? Or was that the few months I spent ferrying tourists from SFO, keeping the saps out of gang territory?

What I hated about that job was that everyone wanted to see the Golden Gate. Stupid idiots. For one, that’s right in the middle of gang territory, for second, all the locals know the real reason why they still call it the Golden Gate - everyone pees on it.

But I guess corporate drones have to go into Facebook HQ sometimes too.

Between coding moving mostly to Mexico and South America, and the new gold rush in biotech, I’m surprised anyone comes here.

Oh, and if I see another ad for Biogenering Bootcamp I’m going to go crazy. Teach me To Bio my ass. A decade or so ago was the big u-cyber gold rush in Japan. Twenty years before that it was robotics, fifteen years before that it was house computers. Before that… well, whatever.

The robotics rush - the last gasps of Big Startup.

Dad saw most of that.

Up through the house computer boom and including some of the robotics rush, you had people for the most part working for money, almost all the time. Dad pulled down a salary most of his working life.

Now a days people are lucky to get a job compensated with some stock options. Paid with actual money? I laughed the first time Dad told me that.

“Yeah, sure Dad — today half the people in this city are working 60 hour a week jobs in exchange for cafeteria meals and some blankets, and you want me to believe that you got paid money?”

Dad got sad after that. I was almost sorry I brought it up.

Gotta go. Ping from Liz - we’re doing some gold mining tonight. Hoping to get some good drops that we can sell to some engineer’s kid in Mexico or something.

There’s a blog entry called: Please don’t learn to code that has caused quite a stir.

The basic point is the author disagrees with the latest fad, calling “2012 the year to learn code”.

Some responses to the entry:

• Please don’t become anything, especially a programmer
• JEG2: “[The mayor]… said he was going to learn something new”
• JEG2: “that article says programming helps you learn to solve problems. That’s bad”

I think most of these responses conflate two things:

1. People picking up a new craft to better themselves
2. That the craft has to be programming.

(The second point) think is the incorrect attitude.

For example, sometimes technology doesn’t solve problems, because those problems are people problems. On a large project I once said to a co-worker, “These guys could have Star Trek (TNG) levels of technology and it still wouldn’t solve their problem… why? Because it’s an organizational problem.

So on that point I agree with the coding horror entry: more code might not solve your problems. Better management might, or developing a procedure for humans to follow.

I wish the movement was “A Year Of Khan Academy”. Yes, please, enroll and learn something interesting.

But it doesn’t have to be programming: you don’t need to feel forced down the programmer mold.

If you’d like, you could make 2012 the “Year Ryan Learns X”. It could be sales, hustling, marketing, physics… it could even be programming if you desire. I learned to play the sax in high school and it was fun!

Yes, the 21rst century needs programmers, but we also need people who can manage, do sales, do bookkeeping or financial analysis, paint pictures, play music, and roast coffee. Even learn to be a better manager.

The Please don’t become anything entry has an awesome paragraph in it (the rest of the article I think misses the point):

Finally, I’d like to tell you that the best way to get good at something is to not attach your identity to the activity. I do say I am a programmer, but really I mean I’m a person who writes code (and does a bunch of other stuff). The skill of coding is not who I am, it’s just one of the many things that makes me the complex interesting person I am. Who am I? I don’t know, or I at least can’t describe it in words.

In one way every startup is bootstrapped - everyone has a number of hours they can afford to bet on the company before something else comes in the way.

You can see this to the extreme in early days, sweat-equity based, startups, but it’s not just a symptom of that method of work.

Be that “Well, I really need some money this month to pay rent”, or “I’m doing this on the side, nights and weekends, and work got really busy and I have to back-burner this for now because I really need to get this work project done”

Maybe this is “Well, another job came along and they’re paying actual money, so it’s hard to say NO to that, especially when this venture isn’t paid.”

Maybe it’s human capital: one too many arguments, one too many heated debates, and one side realizes they aren’t getting paid to take this crap any more and walks off.

Maybe it’s frustration that your cofounder can’t put in the hours you think they should. You don’t think they are pulling their weight.

All that has a cost. Maybe not a dollar cost, but a cost in the capital of your business. In sweat equity startups that’s human - or talent - capital.

Actual money helps relax some of these pressures on capital. There’s less stress about a dwindling bank account, or significant others nagging about, “When is this thing going to make money?”. One more argument that doesn’t end in someone packing their bags because “no job is worth this hassle, and I’m not even getting paid!”

So get creative with funding. Maybe you can start a consultancy together, or be creative and use some of your sources of capital. Maybe someone has some cash saved up and they can invest some into the business for more equity. (or real world equity they can leverage - second mortgage on their house?). Any founder in the venture that has some capital they can leverage to infuse some cash into the business should be welcome to do so.

As a side note: “Should be welcome to do so” does not mean, “Must do so”. Maybe I’ve already funded my own business and don’t have the resources to fund your idea also. Or who knows - maybe I’m flush with money from my last exit and can defer salary until next year if I have to, but maybe some of that money isn’t liquid yet.

Maybe one party is putting in more hours or experience than another, or has valuable skills/connections/background whatever. “I’m a business person, I’ve spent 10 years in industry Y, and I’m founding a startup to disrupt industry Y” is more credible (and brings more to the table) than, “Well, I want the app to be a combination Foursquare and Groupon, because I’m always on my phone and I’d totally use that app!”

To me the business cofounder (I hate the word “non-technical” and refuse to use it from now on) has one major responsibility: remove impediments out of the way of the technical team.

Yes - the business cofounder’s responsibility is being a good manager. Not in the sense of “What’s the status on Ticket #23? You know we really need that by COB today”, but in the sense of “How can I help you do you work in a more productive manner?”.

Money might help people work in a more productive manner. If I know I can work on your startup and get paid for it, and not have to moonlight either your startup work or my “food and rent” consulting business, that allows me to be more productive in my job for you.

Money might also help reenforce the fact that the startup needs solid, deployable solutions, not engineers running around playing with some pet or obscure language under the guise of, “You pretend to pay me, I’ll pretend to work for you.”

Another thing that helps people work in a more productive manner is helping to define specs, fund raising, gathering customer feedback, market research, communicating needs and deadlines to engineering (then rejiggering things when engineering pushes back on those needs).

Oh, and answering business domain questions from your engineers: “What about (stupid detail X)?” might feel picky and naggy to you, but it might be very important to making sure the product behaves correctly.

Likewise, the more you (as the startup in general, but specifically the business cofounder) can understand what your customers want, the better you can tell your engineers what to build, and hopefully the less time or capital you’ll waste building something that will get thrown away in a month.

It’s fun thinking about your idea, but there’s actual work to be done. Be that on the engineering side (writing code, distilling behaviors, pushing back on features or suggesting potentially awesome alternatives), or on the business side (managing your team, understanding customers, marketing, making calls, and hustling).

Running out of capital can also mean one side feels taken advantage of, “All you want out of me is free work!”. (Or its counterpoint, “Why am I the one doing all the work around here?!”) Thus I suggest each founder be highly visible to each other. Daily standup meetings (or twice a week, if both founders are part time) can help, “Oh, Bob’s doing work over there and in generally kicking rear and taking name - I’ve been slacking and should pick up my game”.

Human capital is hard - with cash capital you know what your runway is. Human capital you have no idea that half your engineering staff has been just waiting to quit, or that your designer goes home every night, eats ramen, crashes on their friends couch (just like every night for the last 6 months) - while wondering if/when their friend will kick them out.

This was originally going to be a comment on Hacker News on this thread, but there’s too much cognitive dissidence to overcome so I’m posting it here.

It seems to me there are three basic “startup salary ranges”:

1. Very Good.
2. Less than market rate, but with equity
3. No pay, but with equity.

The Very Good is an interesting market force right now. You expect the best people to jump ship into your company, then stay there for a while. Now, when your strategy for hiring talent is “poach from Twitter - their office is right down the block!” I can see how Very Good salaries can happen. (Or, “We have to pay them well so they don’t go back down the block to Twitter”). Especially when you have to hire rock stars, and they have to be in SF.

In this situation, sure you’ll have plenty saved up no matter which way the startup goes: you don’t have time to spend money on anything more than the monthly bills you have to pay. ESPECIALLY if your monthly bills don’t include rent (or, I’m guessing, a car).

A sidebar here: the comment I was going to reply to talked about living on someone’s couch while spending 6 months working on a startup.

In the “less than market rate” strategy, hopefully that amount’s enough to live carefully and also slowly build up your savings account a little, again for “no matter which way the startup goes”.

Sure, you can still make really good money in this strategy if you’re couch surfing.

In the “no pay, but with equity” situation… well, I hope you started with a good savings.

But wow, I guess you’re just paying for food and (student loans?) if you’re staying on someone’s couch. Brilliant!

And, of course, the couch surfing bit is unrealistic for a huge chunk of even the programmer population…

Let me get political for a moment. The political landscape has been transformed with talk about the character Julia

For those of you who don’t think it’s bad out there for grads, let me present another character, Rickey.

Rickey, a young lady just graduating high school, decides to go to college for management. The economy’s starting to get poor, but a solid business degree should be a good bet.

During college She works a series of part time jobs, usually at minimum wage. This helps out with books and some things that Rickey needs, but it doesn’t come close to paying all the bills.

During summers she held unpaid interships to help her network connections and fulfill the internship requirements at her school.

Rickey graduates her college with a degree, and $20,000 college debt and $3,000 credit card debt.

She graduates, but has a hard time finding a job. Talking with some friends they all know someone who is either still looking for work, or doing food service or retail.

Rickey eventually finds and takes a job as a secretary. Many of the wanted ads for jobs require 3-5 years experience, which Rickey (as a new grad) doesn’t have, so she’s lucky to get this job.

Rickey lasts a few rounds of layoffs, eventually finding herself doing her original secretary job plus managing the website, doing the books, and (with this last round of layoffs) managing payroll.

She finds a boy and gets married. She brings $15,000 worth of debt to the relationship, and he brings $25,000 worth of debt. Combined they also have approaching $10,000 worth of credit card debt

Rickey opted for a very simple wedding, and the couple spends about $6,000 when everything’s all said and done. This is far below the average cost of a wedding (a website calculator says weddings in her area cost $18,000 to $30,000), so she’s pleased.

The happy couple waits a few years and has a baby. The admission costs alone to have the baby approach $20,000. Their health insurance pays most of that, but they still have $3,000 worth of medical bills. They also need to move up to the family insurance plan at work, which costs more.

Daycare for the small one costs about $18,000. That takes a good chunk out of the budget.

Rickey and her husband know they need to save up about $200,000 to $300,000 for Baby’s college education. They aren’t going to be able to save as much as they should for baby, as they are still paying off their own loans, but… they save as much as they can.

Thanks to the Family Medical Leave Act Rickey spends 6 weeks with her baby before feeling she needs to go back to work. When she returns to work she’s informed her job has been furloughed. They don’t know when they can bring her back..

Somehow Rickey gets the feeling they aren’t going to call her back.

Unemployment helps, but not really. Her husband manages to snag a part time, night and weekends job at the mall, and that helps a bit too.

Eventually Rickey finds another job. She manages to do so before the 6 months of unemployment run out, and she feels that she was really lucky to get a job.

Rickey just hopes that social security will be around for her, as the couple’s “nest egg” at this point is maybe a third of a down payment on a house. She is not that optimistic, given how her financial life has been so far. 2050 is a long ways away.

On a personal note: Every day I thank my stars that computer programming is in demand, and (normally) well paid. I have some of the same problems as Rickey, and some of them are more easily solvable. Some aren’t: There’s not $1,000/month in the budget to put away for Vivienne’s college fund. I know it’s better for us though: I know people who make - or made - $1,000 or $1,500 in a month at some jobs. Still: so many bills we have to pay…

I was reading Waterfall’s Demise and Agile’s Rise, and it made me think about the definition of words.

I’d wager that if a developer goes on 100 interviews, that 98 of those companies will say they are Agile. The other two companies will remain silent on the matter, because Agile “what developers crave”.

(Like Brawndo: It’s got what plants crave)

What is important here is what they define agile to be.

In college I trained to be a pointy-hair boss, and my business school alma-mater was all about Quality. There’s a correlation here: if you interview 100 companies, I’m sure 98 will say they do quality work.

What do they mean by quality?

Do they mean:

• Total Quality Management?
• Six Sigma?
• Someone in the building has a copy of Juran’s Quality by Design?
• The business focuses on delivering business value to our internal and external clients?
• Someone in the building read the last half of Zen and the Art Of Motorcycle Maintenance?
• “We try not to build stuff that breaks”?
• “Don’t have your stuff break in front of the boss, or have him blame you about some stuff being broken.”?
• “Quality - oh yeah, we’re supposed to care about that. It’s in our mission statement, I think. I don’t know, I threw that paper out with the rest of the crap they gave me when I started here.”?

So, if you’re interested, you really have to dig to figure out what is meant by quality.

As an aside: Even if you don’t care about management, I think every knowledge worker’s life could be enriched by Juran’s book and ZAMM.

So, back to Agile.

So, what do companies mean by saying they are agile?

Do they mean:

• “We practice Scrum”?
• We practice Kanban?
• “We don’t need a plan - we’re Agile!”?
• “You developers go build your thing, then after you’re done we’ll tell you what’s wrong with it”?
• “Sure, we’re agile. Wait, what’s the Agile Manifesto - is that something new? We should send someone to be certified in it!”?
• “We practice waterfall, but we call it Agile. We also like to call our our databases ‘virtual filing cabinets’ - we think it has more mauve.”?

I would suggest learning what a company means by Agile… maybe even what a company means by Quality.

AFter the post about Scaling Draw Something, well it’s your typical story about startup crunch.

On Twitter, @qrush says:

“…why is this a badge of honor?”

I’ve been in those places before, and I’d like to write about one such experience here:

Management/the customer set a hard deadline of Valentine’s Day, 2011 to roll out the completely rewritten version 3.0 of the system.

When we heard about this deadline in October 2010, us engineers did some agile velocity calculations and realized we needed to get 2-3 times more work done per iteration than we had traditionally gotten done. We told management this, and scope seemed to decrease a little bit (it felt like 10-20%).

There was lip service paid to keeping scope low. Each iteration, we had “pre iteration planning” meetings between some developers and some business people. The ones I were in never resulted in the level of scope decrease we really needed. We needed business to say, “Ok, I guess we only really need 3 of these 6 tickets we brought you”. Instead we got, “Well, I guess we don’t need to implement that side case of this ticket for Feb 14”. Small reductions - nothing major like we really needed.

The reductions in scope weren’t enough, so we worked about 60 hour weeks through January. My personal logs from that time period show one 13 day “work week” - from one day off to another.

The weekend before Valentine’s day we pulled about an 80 hour week.

The stage is set, in a nutshell. See also a previous entry on this blog: Lessons learned over the last 72 hours, to understand more of my mindset during that time.

Ultimately, two things:

1. We didn’t make our deadline
2. Even if we had shipped software, we would have had no programmers awake to support it.

This second item was more critical than normal, and requires some background: This was a production critical workflow app for the client. How production critical? Some parts of the workflow had to be completed within 4 hours, or everyone had a risk of losing their job. Legally. I’m not joking. On the magnitude of several thousand people.

It wasn’t some game, or Twitter, where you have people caremad when it goes down - if there was a bug found in certain parts of the system, turnaround had to be measured in hours. Worse case scenario (not all parts of the app were like that), but still.

So we were rolling out a new, probably buggy version 3.0. We worked 30 hours the Saturday and Sunday before Valentine’s day. I believe some people worked until 6am Monday morning, then went to bed. (I went to bed at 4 am because I had a 7 am train to catch to spend Valentine’s day with my wife.

“Wait, wasn’t Monday the day you were shipping software?” Yes
“Umm, ok, was it done?” No

On Monday morning communication had fallen apart. We had one guy working remotely from India who had no idea what was going on, and I spent a great deal of the (3 hour) train ride back home trying to piece together the status of everything: keeping him in the loop and understand what happened in the 3 hours I was sacked out.

We also had two guys working remotely from various places in Virginia, who also needed to be in the loop but weren’t.

I’m not sure how I safely drove from Harrisburg to my house. Wikipedia has a good entry on Microsleep, and my wife observed me taking microsleeps a few times after I arrived home Monday evening.

Monday everyone staggered in at noon and tried to ship software (I was still on the train). Tuesday morning I woke up - again, with no idea what was going on, and assuming I would play emergency production support developer for a day or two.

Then the hard truth hit the team

We were discussing manpower in our developer-only chat. One guy was asleep in an office, a few were asleep at home, one guy had been up for 24 hours, and we still had tons of work to be done. Some in the chat thought another day of hard pushing would finish the release. I (and others) disagreed: sure, we had more work to do, but we also needed to be there for production support of this critical system.

We realized we were at the end of our rope as a dev team. We told management this.

Personally, the only choice was: “Stop working and go to bed”. If we had been forced to press on I would have turned my machine off, turned my phone off and went to bed. There really was no second option for me. I half wonder if other folks were at that point also.

Management (wisely) decided to delay shipping the software to the full company. Data entry people were entering information twice (once into the old system, once into the new) for a few days, if I remember correctly. I’m sure we burnt a lot of good-will in the rest of the company also.

Moral of the story #1: No matter how hard you push, make sure you leave engineers available for production support

My hour logs show that the week of Valentine’s day I worked 37.5 hours. My hour logs show that the next 2 weeks were still 50 hour weeks. On about March 7 2011 I told everyone I was leaving, and on March 17 I did.

From what I hear from those remaining, it took about 2-4 weeks to dig out of the technical debt incurred over those 3 stupid months.

Moral of the story #2: Crunch means technical debt

Moral of the story #3: When you’re paying your engineers by the hour, that kind of crazy crunch is -crazy- expensive

When I left, the team of 8 engineers was down to 4. A few months later (August 2011?) it was down to 2.

In general, that team suffered something like 300% attrition during my 18 month tenure.

Moral of the story #4: Be prepared for engineer loss after crunch time

Conclusion

I don’t think of my experience as a badge of honor. I hope this entry doesn’t make it sound that way. I’m proud of what the team accomplished, and the professionalism that kept us going. However, the tremendous costs to the people, the team, and the client far outweigh any “I survived” pride I might have.

Yes, shipping software on a crunch is something that happens. However, it’s both a massive strain on the team that goes through it, and on a personal level for each of the team members. I sometimes half joke that the experience gave me some Post Traumatic Stress Disorder. It’s only half a joke. I still get super nervous in certain situations, and may have certain mental blocks that weren’t there before.

(Those of you with diagnosed PTSD, I’m not treating your condition flippantly at all. A little taste of it makes me appreciate what you go through. My prayers/well-wishes are aimed your direction.)

I also learned a lot about managing agile teams, which I’m planning on writing more in depth. I’m writing a book on lessons faced by that team and others trying to practice Agile software development. A lot of the problems that happened on that team I see with other teams too - I’m sure this book could be a help to you: Yay We Are Doomed - The Agile Book

I’ve moved as much of my consulting terminology away from the word “estimate” as I can.

Why? Because “estimate” is often conflated with “a guarantee of how long it will take”.

Imagine this conversation:

Me: “I estimate it will take 4 hours to implement this feature”

Them: OK

(Me goes and does the work. It’s harder than I expect, so it really takes 8)

Them: “Umm… you said this was going to take 4 hours, but it took 8”

Me: Sorry, it was harder than I expected…

Them: But you said!!!

I’ve been luckily lately that I’ve not had to fight that fight in quite a while.

However, using an abstract term like “Story Points” in Agile Development bypasses this fight. Story Points are abstract, but team decided, concept gauging the relative difficulty of work.

On a previous Agile, Story Point following, team, we had something like the following story point structure:

• 1 story point: a one line change
• 3 story points: adding an email notification into the system (we did this a lot)
• 13 story points: Writing a dashboard view like the one for (Role X). (We did this a lot too)
• 40 points: 2 engineers working on something for about 2 weeks

Notice that all of these (except the last one) talk about work we did as a team: adding email notifications, writing dashboards, etc. These were all classes of things that our team did really often, so we had a good idea how big the task (that we were currently sitting at the table estimating) was, relative to other tasks we performed.

In our original case of the blown estimate, story points avoid this situation really well: because they’re not tied to a real world measure, using story points avoids the “Why did this task take you an hour more than you said it should?” conversations you have with nervous clients.

Because what you’re measuring with story points is not time/money, but difficulty compared to these 3 or 4 known reference points.

And fuzzy concepts like that are hard to make pinpoint accurate estimates about: “Ryan, you said you would be done with this by 2:30 PM today, why is it not done yet??!!”.

Recently the Rails community got their panties in a wad about the Kickstarter for Rails.app.

I disagree with Yehuda’s methods, but I do agree that there’s a problem. Follow me down the path of installing Rails on an OS X machine, in the eyes of a newbie:

1. Hmm, I need Ruby 1.9. OS X comes with Ruby 1.8. Ok, umm, how do I build 1.9 on OS X?
2. Oh, people are pointing me at ruby-build or RVM
3. “WTF Make not found?!!”
4. Oh, I need to install a 2GB XCode, off the App Store. OK.
5. Darn, someone pointed out that I could have downloaded some Unix tool thingy at a tenth of the size. Whatever. I can use XCode as an editor, so I guess that works.
6. rvm install 1.9.2
7. rvm use 1.9.2
8. gem install bundler, because someone told me to.
9. WTF?!! “Failed to build native extension”.
10. Great, pass some oddball command to rvm and it worked
11. Ok, I need to install MySQL because I need a database. I hope this one labeled 10.6 works, and I hope I get the right format and architecture
12. gem install mysql, because someone told me to.
13. Could not build native extension. Again. Same error message, different reason, and a different solution. This is getting old.
14. Great! My setup’s all working. Oh, there’s an update to OS X? Better download that…
15. WTF broke now?
16. Ok I fixed it.
17. Great! My setup’s all working. Oh, I have updates on the Mac App Store. I better Update All.
18. Hmm. I got a new version of XCode. I hope my Ruby didn’t break.
19. Why do I need to bundle exec everything?! (Oh, there’s a solution for that?!!)
20. We’re moving to Ruby 1.9.3. rvm install 1.9.3. Great, another error

Some of these are exaggerated, and some of these have been resolved by the community at large. A few of these stump even me, a professional Rails developer. Example: I haven’t been able to build Ruby 1.9.2 since Xcode 4.3. Yes, I know: rvm get latest, and pray.

This is why I do all my Rails development on virtual machines, thanks to Vagrant and Puppet. With Vagrant + Puppet I have an environment I totally control, and I know will remain stable (and reproducibly stable).

We’re also discounting people who have to try the latest and greatest, like the OMG I’M A DEVELOPER, SO I HAVE TO RUN THE MOUNTAIN LION BETAS TO DO PRODUCTION WORK people.