Why is it so difficult to ship?

The general opinion on this forum is that it's difficult to "ship" software, and that it requires special skills.

By shipping, I mean: integration of the various modules, making sure the UI is ok, documentation, lots of testing, fixing the final bugs, making an installer, lots of testing again, repeat until very few bugs, then ship!

For example, from another thread:

> I'm hard pressed to think there's an
> oversupply of:
> - People who know how to ship a product,
> soup to nuts

I have "shipped" software several times. I don't find it that difficult. In my opinion, the only special skills this requires is common sense.

I'd like to see an explanation.

Why do you consider that it is so difficult to "ship"?

Why can't most people ship software?

MX
Wednesday, May 26, 2004

I think most *developers* could manage to ship an app.  However, most *organizations* seem to have a hard time of it.

Although I cannot say that it is always the case, my personal experience has been that when software does not ship on time it is because of obstacles that were placed in front of the dev and test teams by non-technical staffers who lack even a basic understanding of what is required to build and ship an app.

-Managers who try to command rather than serving as advocates.
- Salesmen who commit to delivery dates and feature sets without consulting anyone.
- Execs who stick their nose into how the actual code is written.

Things of that nature.

And, of course, there are the developers who choose to waste time obsessing over relatively obscure details of the code.  But they aren't as much fun to pick on.  ;)

Norrick
Wednesday, May 26, 2004

Being able to "ship" I think primarily means being able to stay on schedule and budget despite the organizational obstacles Norrick alludes too (including such things as losing half or all your developers to other projects, if management thinks you guys are on schedule so could 'spare' some people 'for just a week or so').

It's also being able to make some semblance of a product when you're handed a contract that some guy in another division wrote the specs for, and some other guy came up with an estimate, and some other guy put a budget on it, and it's the first time you've seen it.

And a lot of developers just don't know where to start, how to architect a system, how to divide up tasks that minimize logjams and keep people moving, how to track and make sure all requirements are being handled so you don't get suprised at the end. They don't want to have to prioritize things, or take shortcuts where necessary to keep on schedule, they just want to be told what task to do next, implement them at their own pace, and leave promptly at 5pm.

Getting the product out the door and payment in hand despite everything that typically goes on or can go wrong is what is meant by being able to "ship."

Ron
Wednesday, May 26, 2004

The OP said:
<In my opinion, the only special skills this requires is common sense.>

Don't you know that the common sense is the least common of the senses?

Please do share some of what you know because to me it might not be common sense.

Poof
Wednesday, May 26, 2004

How can something like shipping software be common sense? 

Common sense should be stuff like looking both ways to cross the street.  Are you really suggesting that integrating software modules is as common as checking for oncoming cars?

nathan
Wednesday, May 26, 2004

If i told you here's a recipe to make a meal and
the recipe had 1,000,000 steps and all these
steps must be executed perfectly for the meal
to turn out, do you think you could make the
meal? Now if i tell you won't know a lot
of the steps until you get deep into the
recipe, do you think you could make the
meal?

It's hard. When it does work it's because
smart people worked their ass off.

son of parnas
Wednesday, May 26, 2004

"It's hard. When it does work it's because smart people worked their ass off. "

I'm not sure it could be summarized any better than this.

- Dave

Dave
Wednesday, May 26, 2004

"It's hard. When it does work it's because smart people worked their ass off. "

and their other halves/families didn't mind only seeing them 3 hours a day for a few months before shipping.

Not Waving But Drowning
Wednesday, May 26, 2004

I ship every single day. It's so easy man. I sell mail order socks though.

Cosmo will be back soon!
Wednesday, May 26, 2004

Being able to ship also requires that the developers be disciplined enough to keep the system in a shippable state.  This is where the axiom of fixing bugs before writing new code is extremely important.  If the system isn't stable, you can't (responsibly) ship.  And if the bug list gets too long then predicting the amount of time required to get the system back to a shippable state becomes very difficult if not impossible to predict.  I realize this is software engineering 101 but then again common sense isn't exactly common.

I do agree that one of the tougher things for many (most?) developers is to figure out how to divide up the system into tasks so team members can be working at the same time rather than constantly waiting on each other to finish a dependent component.

Jeremy
Wednesday, May 26, 2004

The ability to "ship" has to do with commercial software. I say this because of statements like "when you're handed a contract.." because that is a different beast (not easy no, but not the same thing).

While some internal or custom implementations may be VERY complex, they have one advantage: some level of control. With commercial software that isn't true.

Developing an accounting package is very hard, implementing something like Solomon is extremely complex, but getting QuickBooks to install on every supported O/S....

Getting someone who has the unique combination of skills necessary to ship high-quality commercial software is quite hard.

And please don't take this as a knock on other developers. It isn't at all. The skills required are just different.

Marc LaFleur
Wednesday, May 26, 2004

You mean "shrink-wrap", not "commercial". Contracted software is commercial too (as opposed to non-profit?).

Shrink-wrap software is easier to ship than contracted software, because you can always leave out features if you need to meet your budget or ship date. Not so with contracted software that has a list of requirements that you have to meet to get paid.

Ron
Wednesday, May 26, 2004

Shrink-wrap is usually far more demanding because it must run without flaw on a wide range of different machines and handle a larger number of circumstances.

By comparison corporate applications can be and often are installed by the vendor, and lengthy installation routines are no problem. Routine maintenance by the vendor is also common.

Thursday, May 27, 2004

A project may have several programmers, each working on a different portion. Combining those components into a functional product can be a challenge, for a variety of reasons:

-- People are running behind
-- Pieces don't work together correctly
-- Functionality may be missing
-- Nobody may know how to set it all up
-- Load tests haven't been attempted
-- Integrated release notes must be written
-- Tracking down and fixing integration problems in a pain

Consequently, integration and preparing a release is a difficult task that's not much fun. I volunteered to do so at my current job, since I was ahead of schedule and because it had to get done.

Julian
Thursday, May 27, 2004

The hardest part in shipping for small (often one man and his dog) "of the shelf" product shops is in my (limited) experience finding the willingness to ship. Often the product is their "baby", and baby is never finished. there is the evergrowing todo/features/improvements list. Setting a concrete time (vs. it is almost ready), and sitting down with this date as a given and mercilessly deciding in/out on every feature to make the date is not something that comes "easy" for most.
Working on some improvement, something new, is always more tempting than stabilizing the system, writing the manuel (<- major problem for some) and facing that instead of development mode they will now have to go do what it takes to "sell" (<- "gasp", don't all devs like sales work?).

Just me (Sir to you)
Thursday, May 27, 2004

> Shrink-wrap is usually far more demanding because it must run without flaw on a wide range of different machines and handle a larger number of circumstances.

So must a lot of bespoke software.

Thursday, May 27, 2004

Ever read Dilbert?  PHBs really do exist, you know.  If you have worked under more enlightened management, you're lucky.

Wally
Thursday, May 27, 2004

You're right Ron. I should have said shrink-wrap. I agree that commercial software covers contracted as well. My mistake.

That said, I very much disagree that contracted apps are easier. As someone said in this thread, shrink-wrap must be (a) easy to install, (b) easy to use, and (c) work on almost anything. Contractors often can install it themselves (or have an IT that can), can require training, and only need to have it work on limited number of configurations.

Marc LaFleur
Thursday, May 27, 2004

  Recent Topics

  Fog Creek Home