Agile Zone is brought to you in partnership with:

Anne Botha entered the IT industry while studying at university by starting her own company, doing software development and business support. After completing her degree she worked at UCT, lecturing web development. After two years, she joined a software development company as a quality assurance engineer. She gained valuable exposure to industries ranging from retail, recruitment, financial, property and document management solutions. She has worked with both proprietary and open source technologies. She developed and managed quality assurance practice within the company and built up the test team, whose work coverage runs over 15 different projects with both local and international clients. Anne has posted 5 posts at DZone. View Full User Profile

The Undercover Adventure (Part 1): Being a user is hard!

07.15.2008
| 8787 views |
  • submit to reddit

After 3 years of being part of an open source software development team (amongst other things) I decided to do something unusual. I decided it was time to experience life on the other side of the fence. I wanted to gain a deeper understanding of the, at times, chaos and conflict I was experiencing as a test analyst (and later manager) when dealing with the business. I realized, after many attempts to talk to a client over a phone (we supported clients in UK directly from South Africa) that not a lot of business knowledge makes it way into the software development team. Documentation is one thing, but with challenges around accuracy, maintainability and timeliness, it isn't a useful insightful way of understanding a clients business.

I wanted to know more. Much more. I wanted to migrate across the fence and just be a user for a while. I do mean user in the truest sense. I didn't want to have access to IT directly in anyway. I wanted to experience business process and attempt to verbally stroll through organization layers to find answers. I wanted to understand first hand what it is like to be a business person dealing with systems everyday and what they face in just trying to get to their work.

It's not greener on the other side.

So, it has been 2 months (3 days and a few hours) and I am deeply frustrated. No wait, let me be more accurate and less nice about it. I want to rip the phone out of its socket, walk over to the software development department and ask them in a tight lipped tone why they are being so myopic, somewhat annoying and you know, perhaps even stupid. I want to shout at them for their indifference and their lack of response. I want to ask for where their source code repository is, print out every line of code and burn it. While explaining to them that this is what a business user feels every time they encounter a bad implementation of functionality.

I want to put in a disclaimer here before I continue as I know that at times limited situational and premise context are provided in a short article. There isn't a way that I can give you full detail about the last 2 months in their entirety here, so I want to say this. The descriptions and opinions displayed here are based on my experiences and are not a reflection of what lies beyond the bounds of this context. I know that there are amazing teams out there. I have had the privilege to work with them and going through this makes me appreciate them more and how critical it is to have good, solid, well understood software development practices and involved, active and interested business sponsorship and support. It is the stuff that makes the process of building something sweet and the end result sublime.

Taking a stroll through a seemingly solid structure.

Now, to give some detail, I work as a maintenance clerk for an oil company that is in the process of starting up its mine. I am there to build up a reference archive, amongst other things, and generally be a runner and helper of sorts for the planners. The planners are responsible for the coordination and facilitation of all information that relates to any and all maintenance that has to happen on the mine. Oil mines by nature are heavily structured and regulated by the government so everything has an associated paper and approval structure. The process is outlined and you can see the workflow diagram on the walls and in the meetings room. Everyone here takes their job seriously because if something isn't done, and everything here is critical, it affects production and that is very, very bad for business.

Being a clerk has a lot of benefits when it comes to understanding a business. All that is required of me is to listen and learn. I am not distracted by having to manage people or systems (not that I mind those things, but it wouldn't have worked well in this situation). I spend a lot of time just sitting and watching what happens and noting what worked and what didn't. Within the first month a few hiccups immediately became apparent. The team (on both sides, both business and IT) are making really simple mistakes (which would be fine if they were small, but they happen to choose the most costly ones).

There are serious cracks under the surface and certain things creak.

For a week I watched one of the planners struggle with the project management/ scheduling application they use to schedule the work that needs to happen. She struggled for an entire day to get all the data together and after much effort finally managed to get the schedule together. The next day she opened up the schedule and noted that something didn't look right. The data was different. She changed everything and saved and sent it out for review. Halfway through the day she opened it for final additions and again, the data had changed.

I had a look at what had changed and immediately two words leapt into my mind and skidded to a sudden halt. Like a board with florescent lights it read "Test Data". I told her to phone the system development team lead and indeed, I was right. Someone had forgotten (a complete shocker actually) to move the database connection to the production instance and had been using her data the whole week as test data. Now this wouldn't have been too much of an issue had the schedule been for a small team to do simple tasks with no real dependence on each other. However, this is not the case. That schedule feeds several teams that within themselves keep around 29 different plants running.

After that, and a few other experiences that I will blog about later (I don't have enough space to cover all of it here), the planning team now circumvents the system as much as possible so that they can get the work through the door. Something that should have assisted them, facilitated away the silly stuff has just completely failed them. The system is badly designed, badly implemented, clumsy and always a frustrating experience.

Things are swaying on its foundation, but I don't think people realize it.

I spent a lot of time thinking about how it got to this case. I am sure that there are a lot of people working on this. You can't tell me that someone didn't raise their hand and ask loudly why they are deploying something so bad. Then something occurred to me when I started bumping into other parts of the business and I started learning about how things are decided, who makes those decisions and I realized how fluid the business is and how unclear and fuzzy the details are. Most of what has been built here has arrived out of a crises mode approach. It all "had to be done now" thinking meant that investment into the long term, such as having proper codes, proper data entry of assets, proper workflow development, proper system integration never happened. If anything, the system that is in place is a clear reflection of the state of the organization (both including the business and IT).

Systems are meant to promote and assist business value growth and be a pleasure to use. I realize even more than before how deeply critical it is have a full picture of which the end user is and what the purpose of the system is. Systems, when they are badly designed and implemented cause immense amount of frustration and indirectly encourages bad business practice and any long term advantage that could have been gained through it is eroded with each release.

Originally from South Africa, Anne Botha is an independent consultant that now resides in Canada. She has deep interests in quality of software and works with teams to build quality into their software development mindset. Anne is a regular writer and her recent articles include Data Quality is More than the Sum of One Part, and Making Sense of the Terrain. She is currently undertaking a self-motivated experiment to understand the life of a user sitting on the receiving end of a software development team. In the next part Anne will discuss her initial experience and observations about the challenges and frustrations that arise when working within a company where a large mismatch exists between critical business activities and the software that is ultimately put in place to serve them.

Published at DZone with permission of its author, Anne Botha.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Paul Cox replied on Tue, 2008/07/15 - 5:41pm

Brilliant! I was asking a similar question on Geertjan's blog. I also wrote at greater length on my blog as to what I was thinking might happen.

I think this is an area where NetBeans can begin to bridge the gap between the user and developer. 

John O'Hanley replied on Tue, 2008/07/15 - 6:37pm

I love these kinds of stories. Stories about real development projects, focussed on the 'business end' of things.

- John

Anne Botha replied on Wed, 2008/07/16 - 10:47am in response to: Paul Cox

Thank you for your comment. I read through your blog article and it is good to see that people are thinking and writing about the challenges that exist with developer and user involvement in the software development process. I wanted to ask about your suggestion of netbeans as a potential choice for a tool to assist/facilitate building the bridge to connect users and developers, what are your criteria in deciding whether a tool will work?

Paul Cox replied on Wed, 2008/07/16 - 12:19pm

First off when can we expect Part II?

The use of NetBeans in this project is a test of Sun's overall product strategy. We will be using everything Sun has from SPARC, Solaris, Java, NetBeans and network.com. If they believe in their products as they say they do, lets test them on it by making this project a success. That is my attitude / strategy and hence NetBeans becomes the default.

I therefore need to work with the NetBeans community to make the changes to develop tools, interfaces and modules that enable the "business user" to comprehend what the development environment is doing. First off I think the user needs a strong understanding of the Java language. Particularly the part where their thinking or vision can be emulated in the Java language.

As indicated by the comments on Geertjan's blog, the developer community needs to understand more of what a user is doing and what they want. The divisions between user and developers are captured in this article that you wrote.

We say individual silos need to be knocked down. Two of the silos is the user and developer communities. I truely don't know what those interfaces and tools are. But there has to be more for the business users and developers to understand each other. I suggest the area where the most of the thinking and innovation in the NetBeans tools, from a user perspective, will come from a study of Anthropology.

Anne Botha replied on Thu, 2008/07/17 - 2:07pm in response to: Paul Cox

I am currently working on part 2 and I am looking to post it over the next 2 days for publication next week. I am looking to post a chapter per week as I have some core ideas I would like to explore further.

I think that NetBeans has a lot to offer your project and I will be looking forward to seeing what comes out of that effort. 

I do have another question: When you say that users would need to learn Java, do you mean the language as a whole? Or do you have a DSL focused (business) context version in mind?

 

 

Paul Cox replied on Thu, 2008/07/17 - 4:32pm in response to: Anne Botha

I agree with you about NetBeans. It wasn't too long ago that these tools where expensive, and in retrospect, limited. I am very greatful for the community that is responsible for the NetBeans tool set. What I would like to see is that the tools increase in some capacity so that communication with the business users is enhanced. I meant no offence to the community with my previous comments. I want to create further value in the community through enhancing the tools from the business user perspective, and therefore the quality of the systems that are built.

When it comes to the business user we have seen alot of glazing over with respect to technology. They know how to use Word and Excel and that has got them to this point. Going any deeper or exploring what is possible just doesn't seem to be a part of their mindset. I am of the belief that in ten years Java may be as necessary to understand and use as Word and Excel are for today's business users.

If we consider that a Java capable business user fully understood the many concepts captured in the language. Will certainly never be proficient enough to write commercial code. But has the ability to use the high level Java concepts to understand what the developer has done. And could communicate back what may be necessary to fix what is a business logic bug with a recommendation of what he / she thinks is necessary. A recommendation that would consist of the business user stating which classes and methods in the Java Doc were of interest to them.

As users there are many codified levels of business logic captured in the business rules and data models. These provide a very generic and antiseptic analysis of the business. What the user should be able to do is to demand that his / her job function be more automated, and consider many of the nuances of the job. (ie we could make more money if we knew that information, or we could eliminate that cost if...) Stating that, particularly in the energy business, innovation and change are mandatory elements of how the user does their job.

The business user needs to be more involved in the development so that these changes can be captured and value generated for the business.

 

James Imber replied on Tue, 2008/07/22 - 9:48am

> the planning team now circumvents the system as much as possible

This sounds familiar to me. IT is not aware of the problems and thus cannot solve them. Users tend to report the little problems and hide the large ones!

May be there should be an obligatory lunch day where a developer has to have lunch with a user using its software.

Anne Botha replied on Tue, 2008/07/22 - 9:24pm in response to: James Imber

[quote=im-james]> the planning team now circumvents the system as much as possible

This sounds familiar to me. IT is not aware of the problems and thus cannot solve them. Users tend to report the little problems and hide the large ones!

May be there should be an obligatory lunch day where a developer has to have lunch with a user using its software.[/quote]

 

I definitely agree with your suggestion of having an informal session where both developers and users can talk about issues (both real and potential). There is no substitute for face to face communication where you need to solve a problem where both people speak completely different languages.

What type of format do you think would work well for that type of meeting? A heavily structured agenda? Or a "come and discuss what is on your mind"?

Also, what are your thoughts on how to manage the issues that come out of the meeting in such a way that it doesn't "overgrow" its domain (think too many people and too many issues all competing for 30 minutes.... )

James Imber replied on Wed, 2008/07/23 - 2:21am in response to: Anne Botha

As you've said, the user and the programmer speak different languages. The user just cannot understand the complexity the programmer has to face. When I talk about complexity I'm thinking about the huge number of details we have to deal with and not necessarily the difficulty of the task itself.

To deal with that IT create structures to organize all this mess and generally the level of detail is overwhelming to someone who is not used to this madness. So overwhelming in fact that a sane person will refuse to deal with that and tag it all as meaningless.

The structure and paper work that IT create serves also another purpose ( CYA ) and sometimes this becomes more important than delivering something useful.

The last point I want to make before trying to answer your questions is that, as you've stated somewhere, is that people outside IT tend to do a decent job when working in a crises mode approach. As IT needs a lot more planning to do things right, the results tend to be less stellar.

> What type of format do you think would work well for that type of meeting? A heavily structured agenda? Or a "come and discuss what is on your mind"?
I think that many users are unable to imagine what the software will look like until they actually use it. When they use it. When they use it, they are able to tell you what's wrong with it. I've seen that even a paper or PowerPoint presentation of the interface does not help the user to decide if the software will work for him/her. She/he has to use it , punch the button and stuff like that.

A heavily structured agenda is useful ... for the IT person that is. The normal person will try to avoid and/or escape this kind of situation (à la Prison Break). Unless the users are highly disciplined, it is likely not to provide useful results.

A "come and discuss what's on your mind" thing won't work either most of the time. The person will either have too much on his mind or too little.

I think that what works best it precisely what programmers tend to avoid. The programmer's nightmare of constant user input. By that I mean that, after a first analysis, IT proposes a product that must be tested by its future users. The users will then complain about silly and important stuff in no particular order of course. You then modify the program according to their feedback and present the product again. Sure enough, the users will complain again and again. After a few iterations the product will be good enough even if the user is still complaining (they like to whine anyway :-) but the budget or time limit is over.

I don't know to what extend IT, in order to produce anything useful, must be able to interrupt the daily routine of it future users: when IT is done with something and needs the user feedback it needs it now, not in the next meeting. Of course, if you go straight to the user desk and ask him/her to test the new feature (just 15 minutes, please!), the user will tell you that it has no time right now (silly me!). However, you really need that person input now (otherwise your work is stuck). Here management has something to say. They must facilitate this iterative process.

Do you know any company that works like that? Not me.
Do you know any company that doesn't produce many failed IT projects? Not me.

Paul Cox replied on Wed, 2008/07/23 - 10:04am

What about in distributed development environments.  Is video chat or Telepresence, as Cisco calls it, an anwser?  There is a YouTube video of the Cisco product here.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.