Software, Software Development and other Atrocities

Most developers state that it is very difficult to communicate and work with users who do not know what they need. We always complain about users who specify mutually exclusive requirements, change their minds everyday or argue among themselves. We would prefer to work with people who can present clear and detailed requirements... oh yes, that would be heaven. mmmh, However, I think I'm not being fair with users. Some of them really do know their business and are aware of the technical implications of software design. Sometimes the problem is not the user but the developer. Sometimes we underestimate our users and assume that they know nothing and simply need to accept what we are going to develop for them. The problem is that we *don't listen* to them. And if users are not listening to us, meetings become conversations between deaf. This is the worst way to start a software development project.

I was wondering if there were some guidelines on how to deal with/understand users. So far I've read ideas about putting yourself on user's shoes or learning user's language. But, how do you do that? Maybe, if we sorted this communication problem out, we could reduce the level of complexity of software development. Any ideas?

I found this definition of complex in the dictionary: " ...having parts so interconnected as to make the whole perplexing." Complex is related to complicated, which "stresses elaborate relationship of parts." Anyway, for me, a situation (a problem, a business setting, users, etc.) is complex (in the context of software development) when it is not that clear to the developers' eyes and when it cannot be modeled and transformed into unambiguous programming code. There are many things that can make a business situation complex for developers, and I am of the opinion that most of these things are human and social in nature. The technical aspects of businesses are in a way less complex as there is help from formal methods (e.g. software engineering) that have been proved in the field many times.

So, what are the things that make developers rant? Well, I have a short list of things may be familiar to you:

- Excessive and unnecessary control of information. As developers we build a mental picture of the business processes the software is going to serve. This picture is often different from the one users who like to control everything have. For developers that extra control is not part of the "real process" and only adds more complexity to it.
- Users working in different ways and expecting different things from the same system.
- In social processes many outputs can come from one input.
- Free social interactions, users who do not follow formal procedures but who use their brain to decide what to do on each situation.
- Covert channels, informal activities --> things that users do in real life but which are very different from what's in business documentation (i.e. business rules)

I am not saying that if we changed these things, organisations will be clearer to developers' eyes (mmmh, possibly but that isn't my point). I think that there are reasons for them to exist, otherwise the organisations themselves wouldn't exist. What I am saying is that we need to find a way to deal with complexity in organisations, and so far, we are not doing that well.

How do you design social software?
Do you interview users, draw uml diagrams and then create prototypes?
As the user of Social Software is the group and not the individual, How do you account for group interactions and group goals?

So far what I've read in forums is that someone has an idea, any idea... takes the risk and develops it. The software is thrown out to the market and people wait to see what happens. Somehow the software is successful, thousands of people are using it and are sending feedback to the creators. Here we have a decisive point in which the creators decide on the future of their yet successful software. If they want to continue in the market they have to listen to user feedback and alter the software to improve the most wanted features and fix or remove the least wanted. At the end, the software is being used by millions of people, it allows them to communicate as they wish and to create a social network that accounts for their goals as individuals and as a group.

Seems nice and easy, but yet.... this looks like an accident, a fluke, really good luck.

If I wanted to create a business application, something that allows people to work and interact... I would really want to use some ideas from social software. (For me social software is every software used by people.) The problem is that, as this is a relatively new field, there is very little on this yet. ... and I am still wondering about how to adapt software development practices so they take into account the social aspects of the business settings in which the software is going to be used?

Social software is software that enables and/or encourages social behaviour of certain type. It is both, an old and a new concept. Social software has been around the software development field for decades but known by different names, like groupware or CSCW. (You can learn more about the history of Social Software in Christopher Allen's excellent article Tracing the evolution of social software.) Social software is new in the sense that it is an attempt (the first?) to recognise the social aspects of software. So far software and software development have been guided purely by mechanistic perspectives. I don't think this is completely wrong because software is also 0s and 1s in computer chips. However, there is also another side of software which has been neglected, the human and social one. Software is part of our daily lifes, we read our e-mail every day, we read the newspaper online everymorning, we buy online, cellular phones, play station, etc. ... and in business settings it is part of our jobs. Software plays an important role at supporting the social interactions in organisations. Regardless of the type of application, payroll, ERP, workflow, groupware, e-mail or online forum, there are always *people* using the software and possibly interacting through them.

For me, when software developers develop business applications they need to consider two aspects of their users, the user as an individual and the user as a group. So far the user as an individual has been addressed in the guidelines for usability. There are very well known and proven practices that allow developers to create userfriendly, intuitive and attractive applications, that users will be willing to use. However, I haven't seen guidelines for *group-sability* so far. I think that the emergence of social software as a new field would bring more development in this area.

Off the top of my head--> I am not sure if prototyping would be useful for *groups-ability* as it is for usability design. It is easy to sit with a user and design a screen in front of him/her and see whether s/he thinks it is easy to use or not. However, how could we *see* the social interactions happening when a group of people is using a software? I think Ethnography could give us some answers in this regard... (but off course who's gonna pay for an ethnographer to be observing people for weeks or even months while you could be delivering software and charging for it?) Probably an adaptation of ethnographic practices could help, some sort of ethnography which is led by feedback from users.

Adaptability in the Software Development process and in Software itself is one of the main concerns of my research. From my readings about theories of organisations I gather that as time passes modern organisations look for more inventive ways to compete in the market. As this happens, the software that are being used in the organisations become outdated because the organisation needs are changing constantly. So my question is, what could we do to keep the software development machine aligned with the organisation's evolution? I think that an exploration of the concept of adaptation within the context of software development would be useful to find the answer. From my readings in forums I gathered the following ideas:

In relation to adaptability of developers and the development process:

1. The process of evolution in software development practices follows this pattern: Experience --> Reflection --> Adaptation
2. Iterative and incremental processes are designed to allow adaptation.
3. Involving clients/users in developers work helps the process of alignment.
4. There is no single methodology that works in every situation. Developers have to adapt known methods to the problem situation and their clients' working styles.
5. Developers need to change their "attitude" towards development. Accepting that change is inevitable and that requirements will change many times during a project may help developers to adapt easily.
6. If developers thought about software as a service provided by people and not as a product, it could be easier for them to think about adapting software (i.e. their service) to evolving organisations.

In relation to adaptability of business settings and clients/users:

1. Users can adapt better (to technology) when they have already experienced change. After one successful experience further changes are easier to take as people are more receptive to them.
2.The level of adaptability of users to software and of software to the business situation could be improved if users had the facility of maintaining/changing/adapting their software to their needs. (An utopian idea at the moment but may be possible in the future.)
3. Organisation's culture can allow or impede technology change. New, agile methods for developing software are more difficult to be adopted in companies with endure strict and heavy processes.

In relation to the adaptability of the software itself:

1. Software should not last forever.
2. Software adaptability depends on the level of dependence of the organisation on the software. If the software is a core part of the business processes then it is more likely that it will be evolve with the organisation. However if the software is just a support tool then it is less likely that it will be adapted to changes.