Fog Creek Software
Discussion Board




another missed world

Custom software.

All software built for governments would fit into this category, as would (in general) software written for a specific company by another party.

How is this different from internal software?  Well, the standards are much higher.  Also, competition is usually involved to procure the contract.  Finally, customer satisfaction will directly affect future procurement as well as (in government cost-plus-award-fee contracts) profits on the current contract.  (this is by no means a complete definition, just a few points off the top of my head)

It is also different from consultingware, because the software is usually built from scratch.

I'm surprised this was omitted, because I was under the impression that this was the world most programmers inhabit most of the time. :)

On the games front : the no-update thing definitely applies to console and arcade games.  However, PC games (to the chagrin of PC gamers) occasionally have severe problems in early versions, and users are forced to wait for patches to alleviate problems.

And, in the case of online games, users are usually _forced_ to patch their software to the current version to be able to play online.

karb
Tuesday, May 07, 2002

"It is also different from consultingware, because the software is usually built from scratch."

Why is it different from consultingware? I thought that consultingware covers this, too.

Leonardo Herrera
Tuesday, May 07, 2002

Consulting ware usually starts with a product (SAP, People Soft, ATG, BEA etc) which the consultants install, and then customize.  Custom software may be built ontop of other software, but probably is more base level.

A rule of thumb, if you can deisgn your own object model, it is custom,  If you are stuck with someone elses, its consultingware.

If you are Non OO, replace Object with Data, above.

Adam
Tuesday, May 07, 2002

"Well, the standards are much higher."

Is this a common experience? I've never seen externally-supplied custom software that matched the standard of internally-developed stuff. My experience isn't that broad, but even talking to friends in other companies it seems to be the norm.

Darren Collins
Tuesday, May 07, 2002

Internally developed software.  Argh.  I would say that I would never want to  work with internally generated software which was not marketed to the outside world.  Internally generated software, in my experience, has always been bug ridden garbage.

Examples:
1. A symbolic debugger used for a now obsolete 8 bit series of microcomputers.  Generated in house and always a POS.  Never worked properly, always seg faulting.
2. A version contol system, written by a large software company for a large software company that positively sucked.  It was capable only as a file difference tool - and even that it performed very poorly.  No versioning or branching capabilities, used its own very poor file locking system that kept screwing up (which, because of rotten design, would then stall all machines attempting to access the perpetually locked file).  It was less capable than CVS or RCS which are free.  Completely bizarre.

The only exception I've seen to this was automated test software which was written by an internal factory automation group.  This was first class software on first class hardware.  But, even in this case, it was competing against outside companies for the same job.  Therefore, for the group to win the contract, they had to be competetive.  Also, if it did not work properly, the factory line would come to a screeching hault.

Nat Ersoz
Tuesday, May 07, 2002

Darren :

I don't have broad industry experience in this.  I've just worked on stuff for the gov'ment.  The stuff written for the man often needs to be of very, very high quality, since it performs some mission critical task.  The government does not brew much of its own software.

In a way, it is similar to embedded software, in that it is often delivered with hardware (and support).  However, I don't think anybody would call 2 million lines of code 'embedded'.

I think nat hit the head on the nail with the competition thing.  Call it consultingware from scratch, large-scale embedded software, competitively-developed internal software, or single-customer shrinkwrap.  It embodies all those things.  Or just say it's 'custom' software :)

karb
Wednesday, May 08, 2002

Its what is often still called 'bespoke' development, as if we were tailors cutting cloth on the bias to disguise the customer's distended capitalist belly.

Sometimes its consultingwareish where you're jerking around some leviathan product to do what it wasn't quite meant to, like printing on the line of the invoice how many goods are to follow when the underlying software doesn't actually 'know' that during an invoice print.

Sometimes its a completely new piece of code to achieve some specific task or goal in an industry that isn't going to attract full scale product development (usually the client tries to reduce the initial cost to them by suggesting that it will solve world hunger for the sprocket industry).  And sometimes you do get to sell it more than once, and then it approaches the shrinkwrap zone and you have to test to a different order of completeness.

I've been lucky I've had my toe, foot and sometimes drowned in all these different ponds at one time or another.    And although the requirements for each broad type of development change I'm not sure that my attitude changes that much.

What is constant is that clients want Rolls Royces at Mini prices, whether they bought it in a store or 'negotiated' the price.

Simon Lucy
Thursday, May 09, 2002

"The stuff written for the man often needs to be of very, very high quality, since it performs some mission critical task"

Conformance to red tape doesn't imply a high quality... and I would consider business programming to be mission critical as well.  For that matter, if government software fails, we'll just get our taxes raised to pay for it.  Businesses can go out of business if they tried to raise prices too high.

I've primarily done the internal development route.  I have to agree with Darren.  Consultingware... essentially a "product" developed with the assistance of high priced consultants at one company and sold (with customization required of course) to another, in my experience has been the lowest quality I can imagine. 

Internal development quality seems much more dependent on the "attitude" of the development staff and the pride they take in their work.  Lower quality will always be delivered by people without some sort of primary stake in the success of the software. 

Joe AA.
Wednesday, May 15, 2002

*  Recent Topics

*  Fog Creek Home