I Haven't Forgotten, And We Will Never Forget( Steve Gedikian's rant republished)

[This post is Steve Gedikian's Blahgger rant from Saturday, October 16, 2004 - which was last seen on the web on his site on January 20, 2009 - republished here for longevity - I know I re-read it often]

So it's been a little while since I last wrote on this thing. Yeah, it's not that I've forgotten, I've just been busy. But don't worry, this update will be quite depressing and cynical. I promise.

Tom quit yesterday. That leaves me being the most senior employee at Nullsoft. That's not really an exciting proposition. In case no one has noticed, we've lost a lot of people on our team in the past 6 months. Each one leaving with varying explanations or circumstances, but all for the same basic reason.

It's these days that really allow me to sit and reflect. Winamp and SHOUTcast are quickly becoming yesterday's news. We really fought the good fight but in the end lost the war. Our enemy, the machine, was just to great to defeat. Believe me, we tried.

Being acquired by another company has nearly always been the kiss of death. I remember when the founders of Blogger came and talked to Justin and I over lunch regarding whether or not they should sell their company. I think the spirit of our message to them was that if they don't have to, they shouldn't. They'd lose all control and ultimately their baby, it was merely a matter of time. It was an interesting conversation to say the least. Unfortunately, 6 months later they sold to Google.

The thing that I've learned about acquisitions is that most companies who buy other companies have their own plans. When you sell, you must know that you're giving up everything you've worked for and that after you sign on the dotted line, it's all over.

Most of these marriages seem to have a honeymoon. Our honeymoon lasted about a year, for Spinner about 6 months.

When it ends, you won't notice but everything starts changing. First it starts off slow, with little things here and there. For example, they come in and 'renovate' the office you're in and replace all your kitchy and fun start-up furniture with the standard company cubicles. As time goes on, more and more starts being stripped away. Say goodbye to the free softdrinks, the rest of the company doesn't get those, why should you? If you didn't notice by then, you'll get a nice splash of reality when one day you show up at work and you've got bullshit corporate propaganda like 'Members Rule!' plastered all over the place.

Before you know it, all the cool people who used to work with you start leaving and are replaced by transplants from other parts of the company or some lame hire who is only there for a job. In either case, the replacements are less talented and less motivated to help you get your job done then the person who left.

But for those who hang in there, don't worry there's relief. Yes, the wonderful world of layoffs will make sure that those who stick around don't have a choice. This is when all the people who worked their fucking ass off are kicked onto the street, with the assistance of security personnel who make sure you don't steal any paper clips or notepads as you clear off your desk.

Ah yes, the joy of layoffs. Here's how it works. Usually, they set up two meetings, they're back-to-back. The first meeting is where they herd your coworkers into a room and tell them that they've been laid off and that they have 3 hours to clear off their desks and exit the building. The second meeting is where they herd those who are left into the same room (you can tell because of all the used tear-drenched tissues) and tell them that they are the 'go-forward team'. This translates to you're going to have to pick up all the slack your coworkers have now left behind.

The weeks up to the lay offs are especially fun. This is where you and your coworkers all know what's coming and are asked to keep working anyway. If you're truly unfortunate, you may get laid off with a 'transition period'. This is when they ask you to hang around another month or two and train someone else to do your job. If you don't agree, then guess what, you don't get your severance and you're kindly escorted out the building.

As time goes on, everything you loved is ripped from your hands piece by piece. What once was your passion that consumed 60-80 hours a week without a blink becomes a meaningless job. Once you felt empowered, now you feel weak. You looked forward to getting up in the morning to get into work and get shit done, now you wonder when will it all end.

It really amazed me that we held the team together as long as we did.

We stood shoulder to shoulder for a long time, fighting off bullshit, only to be split up and made to report to different bosses. We tried to retain our autonomy with our goal to remain true to who we were and to the millions of loyal users of our products. But it was just a matter of time. There was no way we could fight it forever. We would all soon be broken, irrespective of our contributions and our devotion to what we truly loved.

I can see the end of this chapter of my life. The past five years have had a huge impact on who I've become. I grew tremendously as a person and learned a lot about love, work, and people. When it comes to pass, I'll definitely look back and think fondly of all the great times I had. I'll appreciate all the friends I made and all the struggles we overcame, together.

In the end, I know everything will work out for the best.

-s

Candidate Features

Jim K posted a funny rendition of introspection, that showed that you're wasting your time going through customer change requests, not feature creation requests.

Reading 37 Signals' blog is mind opening. Customers don't typically help define revolutionary jumps in your product development - they ask for things they want - they are focused on what will help them. A customer will not analyze your market and research what will sell effectively. A group of customers will not recommend products to build to win market share from a competitor.

What most feature requests give you is tactical improvement - a small net gain for the product. What product managers need to strive for is the far reaching strategical prowess - setting the product's direction that allows for evolutionary and monumental changes. A strong reminder - when companies lose track of defining themselves and their products, and only follow the incremental improvements suggested, they may end up on a track that wasn't desired.

Innovation is created through research and play, needing trials, fresh ideas, and determination.

What would you do when your program does not do what your documentation says it should

You are a development manager.
You develop enterprise software mainly used on the web.
Your software gets extremely customized for customers by professional services - either from a division of your company, by partners, or consulting companies.
Your company hosts a few customers while the majority deploy your product in their own environments.
A large customer reports an issue which gets investigated by customer support. Support cannot determine if it's a defect at all. Defect ? Of course, it goes to development.

Development is tasked with investigating whether the API in question is defective. Development determines that the code and end user docs don't match, but it`s not known which is correct. So it looks like if you follow the docs it is a defect, if you follow the code it is working correctly.

What would you do ?

1) follow what is written - declare it a defect and fix it
2) follow the code - declare the documentation out of date, fix the docs, and suck up to the customer that reported it

We ended up choosing (1). We changed the code to match the docs because we didn't know why they differed. Our automated dev tests passed. But we failed QA because they had some obscure tests that regressed, ultimately saving our behinds. Reason ? We would have helped one customer and injured several. We certainly didn't have enough characterization tests to prevent changes in the system that were "legacy" and quite unknown.

If your software gets installed at customer sites, you most likely need to create end user documentation. A typical iteration will see a spec created, followed by the code and tests, and lastly the docs. Since the functionality of programs will change over time, and because the docs have the highest propensity of not being kept in sync with the requirements and with the program, I would argue to trust your docs infrequently compared to your working code.

In defense of developing enterprise software

Developing enterprise software is not what many claim - easy. The products created at Workbrain, which has been acquired recently by Infor ( the largest private software company you've never heard of ), are used by some of the largest companies with employee bases of well over 100000( airlines, retailers, governments, manufacturers ). Performance under simultaneous load from reporting, scheduled tasks, and UI access points is paramount and heavily tested to maintain best usage.

I can't completely argue against Khoi's post, but yes, design and usability are continuously improved. When starting a company or product, the first few months will typically see explosive growth, followed by well formed growth, then normal progress. As development matures, more care is needed to minimize the risk of regressions and satisfy the massive population of current users. Separating the core product from innovative new product ideas is a great strategy to keep enterprise software companies feeling new, nimble and competitive - without that, they typically end up giving their products and services away and billing for consulting or documentation( aka IBM ).

Jason nailed the difference in how products are managed at enterprise companies - the users of the system are not those that the software is marketed to and many times not who makes the buying decisions. I wish it wasn't the case but how can you sell enterprise software to individuals ? The good news is that we cater to the users through incremental revisions, feature additions and formed a working group where customers can basically vote to influence a percentage of our direction.

Each time I re-read Paul Graham's essay on "why to not start a startup", I laugh hard enjoying the elitism, but also get pissed because my technical reputation is being eroded. Perhaps many, if not most, business problems in the enterprise arena are easily tackled relative to recent startups, but that is not convincing. Many problems are far too complicated to begin without significant research, as opposed to the ability to craft a website that ranks recently viewed materials or allows you to enter your task list. I'm not saying that developing for the enterprise is dreamy - but don't compare it to old school crap.