The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Are people complex?

I have some thoughts about software development and design that I would like to discuss with you. This is aimed to people who are developing or have developed (customised) business applications. When you design and program software you usually draw diagrams, write code and expect them be accurate at representing the (business) situation they are going to be executed in and at solving the problems they ought to solve. You also want it to be efficient technically-wise, but this isn’t my concern now. Your diagrams, pseudo-code and code are static representations of a business situation. The more standardised and documented the situation the easier design is. If you have a process where form1 goes to person 1 and then to person 2 and finally to customer all of the time, then, designing and programming it shouldn’t be difficult. When this process changes and then form1 changes into form2 or 3 depending on conditions and then other actors, person 3, 4…, enter, design becomes more complicated but possible. In (chaos?) situations where people are free actors, who decide how a process should go depending on, maybe, unknown reasons, developers struggle. Some people would re-engineer or standardize processes. But this in some cases IMHO would limit the freedom of people at work. People are not machines! Here are my questions, do you think that everything that involves free social interactions in business situations brings more complexity to software development and should be changed? What are the things/situations in business settings that make more complicated the design and development of software for you?
I’ll really appreciate some ideas.

 (Disclaimer: As some of you might know I've been lurking on this forum for a few months to observe software developers to gather data for my PhD. Maybe my question would sound a bit abstract to some of you, please bear with me.)
Cecilia Loureiro Send private email
Wednesday, January 12, 2005
"People are not machines", ha ha ha. Well, it depends on the audience. In government work (especially federal), everyone is a machine, with procedures either ...

i) dictated and documented down to the last rubber stamp
ii) entirely in the head of a signle unsackable person

So I suppose it depends on your target audience.
David Aldridge Send private email
Wednesday, January 12, 2005
"social interactions in business situations" are not my problem. The "things/situations in business settings that make more complicated the design and development of software" for me are:

1. Systems that have to handle events in an unpredictable order. For example, if you are trading stocks, changing an order previously entered is vastly complicated by the fact that the same order might be changed by several different parties to the order simultaneously.

2. People who do virtually identical jobs but in completely different ways with completely different expectations of what the software should do for them.

3. Vague, arbitrary and usually unclarifiable rules imposed by regulatory bodies, governments, etc. The IRS is a prime example but there are no end of them especially in the finance industry.

Not quite sure where this fits in, but IMO one of the greatest truths of software is that what your system does, should do, or could do is NOT the most important determinant of success. The most important thing for most systems I work on is WHAT THE OLD SYSTEM DID.

The 'social problem' I see day in and day out is that almost without exception users build their every thought around THE OLD SYSTEM and programmers assume whatever it is is crap and do their best to pretend it doesn't exist.

That's all I can think of right now.
NetFreak Send private email
Wednesday, January 12, 2005
"do you think that everything that involves free social interactions in business situations brings more complexity to software development and should be changed?"

This should have been at least two questions.

1) do you think that everything that involves free social interactions in business situations brings more complexity to software development?

2) do you think that anything that involves free social interactions in business situations in such a way that it brings more complexity to software development, should be changed so as to eliminate this added complexity?

My answers to my questions:

1) No, not necessarily. Sometimes they don't impact the complexity of software development.

2) No. It should not be changed if the free social interactions have a positive value in the process (e.g. helping creativity), even if they have an impact on the simplicity of software development.

This answer boils down to: the world doesn't have to accomodate to the simplicity of your software development. Your software is not the center of the universe.
Daniel Daranas
Wednesday, January 12, 2005
Good points, thanks for the replies!

I was thinking that some of the ideas about social software could be applied in business settings. Businesses are social organizations. However it doesn't seem to be a popular topic. Not even in this forum where the "social interface design" forum was removed. Is this a sign of developer avoiding or ignoring social factors in their work?
Cecilia Loureiro Send private email
Wednesday, January 12, 2005
1: "The more standardised and documented the situation the easier design is."

2: "Businesses are social organizations"

First of all, if you write with very few paragraphs, resulting in a long block of text, it gets very hard to follow your argument (or question, for that matter).

Next, quote #1 above -- this is only true IF the standard you are using to document the situation is a "good one".  "Good" here means it produces a model, which can be confirmed with the customer, which has sufficient detail that it can be implemented, which reveals ambiguities and mis-understandings early.

We have MANY 'standards' for documenting requirements and designs.  The most common ones don't do this.  We are still evolving what makes a good requirements document and model (DFD?  UML?  2167/4198/IEEE 12207/SEI-CMM?)

Now, quote #2 above -- Business's prime purpose is NOT to be a social organization.  It is a major attribute of Businesses that they ARE 'social organizations', but the part is not the whole.  Your argument seemed to muddy this point. 

It is possible many people became software developers BECAUSE computers are so much more predictable and controllable than people (even WITH the .NET framework).  It is also likely that most software development method's entire purpose is to produce systems which leverage what people can do.

It's also possible this is a software forum, therefore the social aspect of what we produce is downplayed.  It's also possible that U.S. business culture in general ignores the social aspect of what they do, in favor of increasing ROI for their investors.

You raise a VERY good point, though.  Do we ignore the social aspects?  If so, why do we?  How important are the social aspects, after all?  And yes, people are complex.
Wednesday, January 12, 2005
I have spent my career working in the health insurance industry building internal applications and adding functionality to existing systems.

The individual person’s social impact on what I am asked to produce is relatively minimal.  I have to be concerned with the individuals as far as usability is concerned but not on how they intend to use any particular screen.  Part of this I believe is the heavy monitoring and regulation of the industry as a whole.  Any time I am developing new functionality or creating a brand new system I have to be primarily concerned with the business rules defined for the process.  So the managers and directors involved develop and document how and why any particular portion of the application will be used so that it will function according to their documented business plan and stay inside compliance issues.

To give an example I may have a screen that is to add comments.  On the surface you would think that this would be simply free-formed text that the end user could enter whatever they wanted into it.  In reality they have strict rules for the formatting of the different types of comments they might add.  This is not a requirement added by me developing it but from their managers.  This constraint may be to help with compliance issues, auditing purposes, or something else that I have no clue about.  The point is even though I am creating a screen that has a 4 line 80 character free form text box on it for comments I am often tasked with editing the contents by specific rules that are dictated by the needs of the business to override the individuals freedom to put whatever they like in there.

But alas I work in a very heavily regulated and fined business domain.  Sometimes the restrictions placed on the usage of functionality is purely to make it easier for the governmental auditors when they come threw on a regular basis and look at everything.  Sometimes it’s to insure that people stick to their training and do not expose the company to fines for violation of regulations and laws.

I do have to take into account individuals as far as usability goes but all I can do is try to design and code for flexibility as they laws and interpretations will always change and I will be going back into the code to inforce this new constraint on the users of the application.

I have run into occasions were one division wants to use a screen or application for a different purpose but that’s usually when the department heads get into a meeting with or without IT staff involved and work out if it is safe and practical to do this or if I need to inherit from this screen etc and create a new one for them.  Sometimes the change is minor and I just make different fields invisible for different security levels and the regulations on whom can see what data.

But the comment about the end users caring more about how the “Old System Worked” is very true.  We often try to create the new systems and functionality to mirror the old applications look and feel as much as possible to make retraining as easy as possible.  But of course I am used to having to work with a trainer to make sure they can document the new usage and business rules associated even if the application does not inforce them.  This is required.  They have to document that they have trained everyone that should be using the application or pieces of it on its proper use to limit their exposure to fines if its misuse violates some rules.
Douglas Send private email
Wednesday, January 12, 2005
“Business's prime purpose is NOT to be a social organization.  It is a major attribute of Businesses that they ARE 'social organizations', but the part is not the whole.  Your argument seemed to muddy this point.”

Actually I said businesses ARE social organizations. Regardless of their purpose, ROI, NGO, etc they still are groups of people working together. AllanL5 you spotted the problem. We focus on business objectives only and forget about the nature of the business itself.  Perhaps, some of the problems in software development - especially at communicating with clients, understanding social complexity and designing models - could be solved if we were more aware of how people and groups of people think and behave.

I’m not saying that we have to forget about the business objectives. I’m just saying that we have to take into account both when we developing software.
Cecilia Loureiro Send private email
Wednesday, January 12, 2005
"Do you think that everything that involves free social interactions in business situations brings more complexity to software development and should be changed?"

Everything? No.
I don't agree with your assumption that it is the increasing interaction paths that makes the design more complex. I would contend that a business is a totalitarian social structure where information is controlled for power and gain. It is therefor this need to control information that makes the design of software more complicated as the number of interaction paths increases.

For example, the www & Internet is used for very complex social interaction but due to the lack of information control it is relatively simple. If I had to get authorisation to view a page from my manager, obtain a view reciept, store my history for billing purposes, fill in a timesheet of activity for cross reference etc it would get very complicated. And that assumes all countries had the same rules. As soon as an individual web site requires authentication is complexity rises. Adding pages doesn't make it more complicated in itself.

"What are the things/situations in business settings that make more complicated the design and development of software for you?"

Basically its the need to control the information for power and gain once again. This manifests itself in the need for complicated securtiy and work flow processes and audit trails.
Wednesday, January 12, 2005
> do you think that everything that involves free social interactions in business situations brings more complexity to software development and should be changed?

I can give you two counter-examples to this if you want;

A) Decisions are made by an expert talking to clients, rather than by a computer algorithm. (Eg, a mortgage recommendation.) The system doesn't need to implement the algorithm, so the system can be dumber and simpler.

B) Decisions made by meeting or committee. Again, what is decided in the social world doesn't need to be solved in the computer world.

A very worthwhile book to have a look at is 'About Face 2.0', by Alan Cooper and Rob Reiman. They look at the subject of system 'fudgability', and also at the determinants of successful software - one of which, they argue well, is the fulfilment of the user's goals and not necessarily the business goals.

Removing the richness of social interaction in a situation might well be against the user's goals (for example, to appear intelligent, to participate in decisions, etc) and so will most likely end up being viewed as simplistic or totalitarian. Which isn't going to help it succeed.
Steve Cooper Send private email
Thursday, January 13, 2005
If forced to polarize the issue, I'd tend to take the opposite view. Design of business applications is feasible because of the adaptive social nature of the business environment that can very flexibly route around even major design issues.
If people wheren't the creative social beings they pretend to be, business software design would be incredibly difficult. The state of the art would probably be some basic calculator, and their would be daily stories about business "crashing" because someone misplaced a stapeler.
Just me (Sir to you) Send private email
Thursday, January 13, 2005
"The more standardised and documented the situation the easier design is...What are the things/situations in business settings that make more complicated the design and development of software for you?"

One thing we struggle with constantly is when there is a standard workflow, but users don't follow it. Sometimes people make mistakes, sometimes they're lazy, sometimes they don't take the time to learn what they're supposed to do; you can never, ever assume a user will perform even the simplest or most important task correctly or even perform it at all.

So what should be a simple sequence of N tasks becomes a horribly complicated mess of prompting users to do something, verifying they did it right, trying to recover when they did it wrong, figuring out what has to be redone, etc., etc., ad infinitum.
Tom H
Thursday, January 13, 2005
I think you have stated something quite important, Cecelia. The more interactions, and the more complex interactions, there can be in any situation the more complex the computer process associated with it is. If a component always has the same inputs and outputs the process for it is easy. The more inputs it must handle the more complex. Social interactions certainly increase that. Even allowing for something as simple as one person phoning another to check on the progress of something requires computer support - the enquiree's computer system must allow for the suspension of what they are doing and switching to the task of getting the information.

To make an analogy, once upon a time, back in the mists of the past, any moderately complex computeristed system was prompt-driven. The user started the process, and the computer asked for the information it wanted in the order it wanted. Such systems were easy to program, which is why it was done. Modern systems are easier to use because the user can enter information more at their convenience; essentially a 'richer social interaction' between computer and user. But this comes at the cost of making the programs much more complex. This complexity has been offset by improvements in the tools we use to program, but they are nonetheless more complex.

There is an analogy too to the complexity of code. One rough measure of a program's complexity is the number of execution paths that can be taken through it. Similarly the complexity of a business system is related to the number of paths by which data can flow through the system. The more interactions there are the more possible flows - and social interaction certainly adds to that.
David Clayworth
Friday, January 14, 2005
Have you read "The Psychology Of Computer Programming" by Gerald Weinberg? It kind of kicked this field off in 1971.

Yes, there's general agreement that you can't really divorce people and processes - they're part of an interlinked system (together with the other forces acting: incentives, external influences, etc).
Matt Morris
Friday, January 14, 2005
You will find that there are (many? a few?) companies where the documented process is different from the way work actually happens in that company.

I'm going to go out on a limb and make the assertion that EVERY failed ERP implementation is one where the implementation team followed the written documentation and did not know to, or follow what the actual processes performed at that company actually did.

Written docs:
The TPS report will be generated from sales data in the computer.

Actual process:
The TPS report is generated from a spreadsheet that Suzy makes.

And the interview goes something like:
Me: why don't you use the numbers in the computer?
Her: they are wrong.
Me: why are they wrong?
Her: well, Bob enters sales for customers to make his numbers look good, and they return them after the end of the month/quarter (channel stuffing). Fred enters bogus numbers. George doesn't enter anything at all, but since he is the "star" then no one can do anything to him. And the VP keeps 4 sets of books, and the computer sales system doesn't have the numbers for the real books, just the ones that the company thinks are real.

Doing incremental deliveries (not that I'm hawking agile stuff) has helped minimize this sort of stuff. If you have some massive code delivery where you just throw the whole new system over the cube wall, you're going to be sorry a lot of the time.

There are a lot of covert channels (and "networking") in business. In the business world, covert channels are used to get work done, find out what the real data is, or to cover up for incompetance/corruption. Every company has a written org chart, and for many companies, the real power and authority in that company is reflected on that org chart. For the other companies, the org chart isn't where the real power and authority lies. I'm not saying those companies are alcoholic or dysfunctional, just that the paper usually reflects wishful thinking: how they want things to be, not the way that reality is.

For a book that shows a bit of how far this can go into the enron/worldcom/anderson end of the spectrum:

I'm going to make another controversial point: younger developers aren't going to be jaded and cynical enough to think that there is a shadow system in the company.

When I was a younger dude, the saying was "garbage in, garbage out." Meaning, if you put garbage into a system, then the output cannot be better than garbage. Nowadays, GIGO means "garbage in, gospel out" meaning that no matter what goes into a system, the output is the word of god.
Peter Send private email
Saturday, January 15, 2005
Software is like painting a picture.  You never really know if the person your painting it for will love it or hate it.
No One
Saturday, January 15, 2005
I was thinking about what Kim said a few posts above. The excess of control of information makes things complicated for software development. But only nonsense control, control that is not needed to run the organisation. Here you have to program software with unnecessary control devices to satisfy the stakeholders’ needs of power. On the other hand, I also believe that lack of control also makes things complicated. When nobody can tell you how things are or should be run in the organisation, and where no one is responsible for nothing. How could you start gathering requirements here?
I think these two extremes make things more complex than they should be. However, in the middle of this spectrum of control there is natural/needed control, where people are working freely up to a certain extent but where also some rules are followed. Maybe these rules are nonsense for some people and maybe these are the people who find it difficult to develop software… who knows.
Anyway this issue about excessive control due to needs of power and gain has made me think a lot. Thanks a lot!
Cecilia Loureiro Send private email
Thursday, January 20, 2005
Oh, the processes people play...
Stephen Hirsch Send private email
Wednesday, February 02, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz