Fog Creek Software
Discussion Board

Lack of Adaptability

Information systems/software act in many ways that damages the organisation’s ability to absorb variety: scripts, procedures, automated work scheduling, workflow systems…

Cecilia Loureiro
Thursday, June 10, 2004

Software automates repeatable processes.

Christopher Wells
Thursday, June 10, 2004

Informations systems increase the efficiency of the unchanging repeated tasks of an organization thus allowing more time for change and absorption of variety.

I like this new format in which the OP doesn't ask a question but only makes a statement.  I am hopeful the results will be quite dada.

name withheld out of cowardice
Thursday, June 10, 2004

Sorry that wasn’t meant to be a statement… just wanted to start a conversation… I forgot to ask your opinions.

By “repeatable process” or “unchanging repeated tasks” you mean something able to be repeated under exactly the same conditions?

Yes, there are some business processes that could be though as repeatable (online purchasing for example)… however, that isn’t exactly right as some exceptions may occur … some conditions may be different and not supported by the software ... so how do we handle exceptions then? Do we include “if-then” clauses all over the code?

Cecilia Loureiro
Thursday, June 10, 2004

One of the biggest problems I see in 'human systems' is that they depend very highly on the creativity and flexibility of the people involved.  By that I mean, seriously crippled processes are put in place, and heroic efforts are required of the people involved in the processes to make them work.  And as long as work is getting done, no additional work is put toward improving the process.

When we seek to automate this, if we automate the crippled-ness in the process, then yes, it is very inflexible.

One of the problems I see with people who WANT new systems is they have a hard time separating the solution statement from the problem statement.  "We need a computer to solve this" is one such "problem" statement.  "Insufficient automation" is another.

In the 1980's, there was a model of system improvement that went:

1.  Characterize the existing physical process.  This becomes the 'old physical' model.

2.  Determine the logical steps done by the physical process.  This becomes your 'old logical' model.

3.  Re-order and re-factor the 'old logical' model.  Remove redundant steps.  Reduce 'wait-time'.  Streamline the process.  Determine the data needed, who needs to know it, and where in the process it needs to be known.  This becomes your 'new logical' model.

4.  Determine who is going to do what, and with what automated tools to do it.  Partition your 'logical model' into roles for people, paper, data, and tools.  This becomes your 'new physical' model.

5.  Implement the pieces of your new physical model.  While doing so, your data structures in your automated parts should 'match' in some way the data being used in the real world.  This 'matching' should minimize the 'ripple' effects of minor changes, giving you flexibility for the future.

Unfortunately, while I see people trying to apply this model, I don't see them having much success with it.  I don't think this is a problem with the MODEL, I think it is a problem with the way some people think. 

They get stuck on step 1 -- they can't come to a consensus as to what their system does, or how it does it.  They get personally attached to whatever their role currently happens to be.  They think in terms of solutions -- "just automate this" -- not realizing they setting an awkward process in cement when they do so.

I believe this to be the major reason automated systems are built with this "Lack of Adaptability".  I don't think it is inherent in automated systems, though.

Thursday, June 10, 2004

Or better yet: Ideally, adoption of software, or a new piece thereof, should be the opportunity for an organization to check whether those procedures are really or still needed in the first place, before spending money automating the process.

Thursday, June 10, 2004

> By “repeatable process” or “unchanging repeated tasks” you mean something able to be repeated under exactly the same conditions?

I mean something that can be repeated or automated (a circular definition, I admit). For example, MS Word has a certain (theoretically well-defined) behaviour when you type on the keyboard. It's used in a wide variety of conditions (by different people, on different machines, for different documents), yet it has automated that which it has automated (i.e. accepting keystrokes, inserting data into a document file, painting the document on the screen, ...).

> some conditions may be different and not supported by the software ... so how do we handle exceptions then?

I think that, if it's not supported by the software, then we change the software (rewrite it, reconfigure it, add to it, replace it with other software), or bypass the software (do it manually, or in person).

> Do we include “if-then” clauses all over the code?

Sometimes, but not exactly; these days, code is often object-oriented: so instead of if-then in one module, you might use a different module than implements a compatible interface; or software may be data driven, configurable, ...

Christopher Wells
Thursday, June 10, 2004

"some conditions may be different and not supported by the software ... so how do we handle exceptions then?"

There are two issues here: What to do (generally a work flow or standard procedure), and How to get it done (very often requires some decisions).

The software should encourage the user to do the Whats, can offer some guidance on the How, but shouldn't stop the user from doing it a different way (manual overrides, extra tasks, etc).

For example, suppose your system processes a patient being discharged from a hospital. There are some things that have to be done (doctor orders discharge, bed linens changed, accounts settled, etc). But the nurses on the floor probably deal with special cases every day that a programmer would never think of. 

Anony Coward
Thursday, June 10, 2004

There are organizations who seem to get it right though. Walmart is considered a good example of this, where software amplifies rather than restricts. Maybe it's a culture thing: good things are accomplished by people who think they're doing something important, and there aren't dogmas in their way. Since the software producers and software users are both human, it seems to reduce to a human problem. Software can not be considered outside the human context.

The people who know more about the machines need to empathize with those who don't, which means there can't be unnecessary antagonism between the two.

I do believe in more organic software (not mutually exclusive with intentionally making software brittle), and you see that not with if-then clauses, but with things like exceptions or conditions. Functions can be very restrictive, and there are things more advanced than exceptions which break out of that paradigm when something unusual happens.

Tayssir John Gabbour
Thursday, June 10, 2004

“I don't think this is a problem with the MODEL, I think it is a problem with the way some people think”

I am afraid I have to disagree … it is both a problem with the model and the way people think…  A model represents the system (not only the software but all the activities surrounding it).  Some people don’t know were they are standing hence they misinterpret what they do what they need … if these people model their system, the model represents incorrectly reality…

And to go back to lack of adaptability… I think that adaptability should be part of the model ... of course it sounds a bit abstract… is something difficult to represent… maybe if we designed more flexible systems,,, if we didn’t specify in detail every single process…..

Cecilia Loureiro
Thursday, June 10, 2004

> maybe if we designed more flexible systems

Part of the solution is to use general-purpose components: for example use MS Word, or and HTML browser, to display text: which works no matter what the content or the format is of the text to be displayed.

Another part is to use data-conversion utilities: for example, to copy RTF text to HTML text (again, without worrying about the content of the text).

Another part is to write modular software, that separates (for example) the business logic from the presentation: so that you can change the UI without changing the processing, or vice-versa.

> if we didn’t specify in detail every single process

As a programmer, that idea is difficut for me to accept: because, if you're talking about a software process, a computer doesn't "understand" or "implement" any process unless I specify it (to the computer) in detail.

Christopher Wells
Thursday, June 10, 2004

“As a programmer, that idea is difficult for me to accept: because, if you're talking about a software process, a computer doesn't "understand" or "implement" any process unless I specify it (to the computer) in detail.”

Good point:

But what if we allowed the user to specify those processes on-the-fly …
If as you said, we used general-purpose BUSINESS components (I added business) we could design processes dynamically while running the applications.

Cecilia Loureiro
Thursday, June 10, 2004


this is he 3'rd (4'th) tread you start on this. Maybe it would help if you stated it in some more concrete terms. Show us an example of a product that fits your criteria. If no such thing exists yet, make up a fixional scenario (Joe Mulch works for Aiginesy, a shipping company. This morning he walks into the office carrying his Tablet PC. Walking past the front desks his system senses he enters the building and does a fast boot to retrieve the mornings email before Joe gets to his desk ... ). Be concrete.

Also remember, a business system is comprized of more than just software systems. It can be very adaptable even though all the software is very inflexible.

Just me (Sir to you)
Thursday, June 10, 2004


Just me (Sir to you)….

Unfortunately, at the moment I can’t be more concrete… what I am doing here is just brainstorming and gathering some useful ideas… hopefully… in the near future I will come up with something more concrete to get your opinion on. 

Until this happens I welcome more inputs on this issue from all of you.


Cecilia Loureiro
Thursday, June 10, 2004

OK, look up a whole bunch of research papers done in the mid to late 80s on expert systems and fuzzy logic. Nothing new here. It's all been thought of befor. Hint: It ain't as easy as it sounds when using buzzword bingo.

Thursday, June 10, 2004

Old timer,
Are you implying that what are not good, innovative enough to help her?
I consider myself and other software developers as very innovative and clever persons always willing to come up with new ideas.

I don't think so
Thursday, June 10, 2004

I gotta agree with this:

>I don't think this is a problem with the MODEL, I think it is a
>problem with the way some people think

and the guy in the last post. I recently was thumbing through a book were the guy contrasted ACCOMODATE with ADAPT. It made a lot of sense and I saw that this guy was had been around since the early 80s and this wasn't anything new.

I got my first computer job around 1997. Got in with the boom, had no formal training but read a lot to make up for it.

My latest fad is config/engine. Determine that which is most subject to change and separate it from the engine.  It makes a lot of sense to me and although I can't place it, this is memory from some books I've read recently.

The config is essentially the data model which depends on understanding how you want something to work.  Rarely, rarely, can I ever get enough information to really biuld the config and the engine. Yet I try. It leads to refactoring as I move things out of the engine and into the config or I create a new engine.

For much of my code I need only modify the configuration. I rarely modify the engine. Sometimes I need to build a new engine to do something. I have a feeling there is nothing new about what I'm doing but the approach by everyone else is to just write all these independent apps which blend everything togehter ... for instance ...  we use forms for users to modify the database. Each user has a combo of read/view/write access so when you create the form you may show some values (read only) if they have view access, or an open form if they have write access (and sometimes this is dependent on other values associated with a record in combination with who the user is) ... okay, so how do you do this? Everyone but me will write a page with if/elsif and printing display elements with data elements ... in one long, big file. I have a config file where I have users, form #'s, permissions ... it gives me the permissions for a user I pass ... I then get the data for a record ... then I pass all of this to an engine which generates the form given those parameters. I can very easily show anyone which users have rvw access to any forms ... etc .. very easy to make changes ... etc. gotta run.

Thursday, June 10, 2004

Fictional scenario (adapted from the Thief of Time by Terry Pratchett)

I wake up in the morning.  Time has stopped.  My software code does not need any change, just because the world has stopped.  A bit boring perhaps, or the ideal for all of us as developers?

Has anyone heard of software evolution laws?

Evolution and me
Thursday, June 10, 2004

> But what if we allowed the user to specify those processes on-the-fly

Then you would have come full-circle: "letting the user specify" isn't the same as "if we didn’t specify in detail every single process": my point is that someone has to specify the process, sometime.

(Because, otherwise, it isn't software?)

Note that even as a programmer, when I call subroutines written by someone else without knowing those routines' implementation, I'm specifying what the computer should do without my specifying how it should do that: in that sense I'm a "user".

Also, users may not be good at "specifying" what they want: which is why you get programmers, analsysts, etc.

You might like to read the chapter "Organization: The Coming Ad-hocracy" of the book "Future Shock" by Alvin Toffler, if you haven't already.

Christopher Wells
Thursday, June 10, 2004

> Also, users may not be good at "specifying" what they want

Although "users" are needed too, because programmers don't know how to specify everything: for example I can write a text editor, but if I don't know which words the users the wants to edit then I give the program a UI.

Christopher Wells
Thursday, June 10, 2004


writing a few hypotetical scenarios is considered a pretty good way of brainstorming.

Just me (Sir to you)
Friday, June 11, 2004

internet wasn't working today ....
i just read your msgs.

thanks for your replies.

Just me (Sir to you)

I completely agree.  I will think about something more concrete. and continue the conversation.... or maybe start another thread.  But take into accont that I am not looking just for answers but for innovative ideas...

thanks again

Cecilia Loureiro
Friday, June 11, 2004

*  Recent Topics

*  Fog Creek Home