Why are there so many sites dedicated to programming and yet there are relatively few that actually describe the systems that they're trying to produce?

Question

There's a lot of sites out there that teach people how to build better software--but why is it that there are very few sites that actually give detailed descriptions of the domains that we (as programmers) are supposed to create? One can only construct so many inventory, accounting, and ERP systems before a pattern of common requirements start to emerge among the different types of systems. Logically speaking, if programmers spend so much time trying to create reusable components in their architectures, does that imply that they should have to have some reusable "blueprint" that describes the systems that they're supposed to create? In other words, it seems like the focus of software development has been too focused on "how" software should be built rather than to catalog and accurately specify (with detailed requirements) "what" should be used in the first place.

So my question is this: Has there been any work done to catalog all the different types of system specifications into a single place, all on a single site? If lacking the proper requirements at the start of the project is one of the banes of software development, wouldn't it make more sense to be able to 'reuse' requirement specifications from previous systems of the same type that have already been written?

Answer 1

There are, but they are usually run by vendors wanting to sell you a solution. :-/;

Answer 2

I completely agree, where is the 'Dummy's guide to inventory IT', the accredited data model for customers, addresses and contact details etc etc. I've found myself re-implementing the same code in so many different places, with subtly different fields and logic but basically the same stuff. A few years back I found a site of pre-cooked data models - a small step in the right direction but not the whole story Universal Data Models (no connection). You'll notice that they haven't had much interest in their product though.

I've also worked in a couple of organisations which were developing their own 'universal' data model as a saleable product. One was in the domain of financial services, and they got to 1500+ DB2 tables, and gave up. Organisations pride themselves on being unique, whereas we (the techs) realise that under the hood most are doing pretty similar stuff - I think it might be too damaging to corporate ego to fess up, and admit they're just the same as everyone else using UniversalCustomer (TM) 1.7. Also that makes these companies ripe for a bit of SAP, Peopleware etc.

As a final thought - there's a lot of low hanging fruit for the entreprenaurs here. A decent set of short books describing common domains. I mean the super simple stuff, persons name, address, telephone etc - with all the little foibles like title in different cultures, and phone number layout handled - now there's a book/wiki a lot of people could use.

Answer 3

Who would create such a thing? Who would use it?

Near as i can tell, you're talking about a library of application designs. The people disposed to sharing such detailed designs are already doing so - in the form of open specifications or open source. The former tends to attract mostly people and organizations already involved in creating products that implement such specs, or products that inter-operate with systems that do. The latter... well, why bother re-implementing the design when you can just hack the source?

As Mark Harrison notes, there are plenty of companies willing to promote their designs for common business systems. "Buy our system, and just bolt on the functionality necessary for your organization", they'll tell you; "why waste time re-implementing something we've already done?" There's really very little motivation for them to share detailed implementation specs, since they really don't want you re-implementing what they're trying to sell you.

Finally... These things really just aren't that complicated. Or rather, they are... but the complexity is born out of size, out of the myriad combinations of arcane requirements that any given organization might impose upon the system. The real work comes in interpreting these requirements, building them into the base system - and tedious though it may be, it's unavoidable.

Answer 4

There's a site Database Answers that attempts to provide solutions for common database designs. That's not the same as a complete solution like you are describing, but it is a step in the right direction.

You comment "[o]ne can only construct so many [...] systems before" the commonality becomes obvious. However, those who have constructed enough such systems to spot the commonality then attempt to benefit from it by creating their version of the common system, and then they sell it. It is not (perceived to be) in their interest to give other people who might do the same thing a helping hand.

Answer 5

It would be unsaleable. The first assertion you inevitably get from anyone distributing an RFQ for a system is: "We aren't like other companies. Our requirements are unique." (And the never really are.)

Answer 6

If you are going to reuse the requirements you might as well reuse the code too. But on a lower level I think what you are looking for would be "requirement patterns", along the lines of "programming patterns".

Now here is a book from Microsoft on the topic, but as with all domain patterns, the idea is that they should organically grow and fit the needs of the domain users and experts. If you want the true source of the idea check out the seminal book on patterns, although it's from Architecture and not programming, surprise surprise :)

Answer 7

There are various efforts by governments to try and standardize data models to enable sharing between different agencies, but these have little to no adoption outside of where it's required. In Canada, for example, we have CPSIN.

Answer 8

Check out the Data Model Resource Book by Len Silverston:

http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1232336996&sr=8-1

It approaches reusable design from the data model point of view, as opposed to end user requirements or OO designs. However, I find that to be very useful - once you have a good grasp of the data model, you have a big jump on the requirements and the entities that will eventually be modeled as classes.

Answer 9

In my experience where it falls apart is the Use Cases encompassed by the UI. I in fact have designed and built an inventory system that's been applied across a broad variety of organizations and industries (telecomms, food products, healthcare, electronics manufacturing and distribution, consumer products, apparel, aerospace, many others.) After the first half-dozen, a good data model emerged that has served with little variation (extension, but not variation) for all of them.

But even within an industry, for any number of reasons (nature of the product, volume variations, average order size in and out, accounting requirements, employee motivation, etc. etc.) the way the work is done by real people varies hugely, for good reasons.

Note that the examples above all seem to be about deeper abstraction levels - specifically data models - where we programmers can do it our way, to our benefit. The closer to the user we move, the more our interests need to become secondary to theirs.

Worst-case example: Has anyone else noticed the pattern in employee-scheduling and workhour-reporting systems to show one week per screen, and multi-screen data entry forms?

Answer 10

There was a huge "Software Reuse" movement back in the '80's and early '90's. There was a sizable industry of people building and tuning catalogs of software components. It was seen by many as the future of software. A good overview is Will Tracz' "Confessions of a Used Software Salesman"; google terms "Brad Cox Software IC", "Martin Griss". As I recall, victory was declared and everyone moved on to other problems.

I see that Brad Cox's "Planning the Software Industrial Revolution" is Online:
http://www.virtualschool.edu/cox/pub/PSIR/

Answer 11

You might want to check out Martin Fowler's Patterns of Enterprise Application Architecture - while not specs, it seems to be about the sort of things you are after.

Disclaimer: I haven't read it myself, I only know of its existence.

Answer 12

It would be nice to have a central repository of code patterns, all variety of languages. Then we can both show off our amazing code, make it easier to learn from each other, and would also improve overall code quality by having good examples of providing xyz service/product.

I mean, how many of our coding projects that unique that no one else has ever done it?

My rough guess is that 98% of our work is stuff that has been done by other people in lots of different companies, similar industries, similar functional needs.

I mean this is the kind of thing that stackoverflow should get behind. To not only share and talk about problems, but to learn from each other's code as well.