Is software development obsolete?

A friend of mine is a civil engineer. He writes his own computer programs. In the early days of computers, I suspect that that approach was the norm. Computers were not for trivial uses, the users were highly intelligent and motivated and they were taught how to program to solve their own problems. They already understood the business and what they wanted.

The era of the professional programmer—one who does not know the business—has been brief, basically from the 1950s. Much of that time was spent on coaxing computers to do established manual operations: accounting, inventory, records management where cutting new design was not a major aspect of the project, we already had a design that worked. But two charactersitics: these are well understood processing domains and the man-machine interfaces to them were clerical in nature.

Nowadays those back office systems have already been written. It doesn’t make sense to write your own.

It also seems that the kinds of systems needed now are those that would help knowledge workers, not clerical workers. And both the domain and the interfaces are less well understood, are highly evolved and still evolving rapidly. Where does this put the average application programmer? Typically they know java, and other programming languages, but not the business. Is knowing java sufficient? It means that someone has to explain the business to them. And if the business is knowledge, can—or should—someone be expected to impart that wealth of knowledge?

Do we need simpler programming languages so that the users again do the programming?  Such that the emphasis is not learning programming but getting on with the design and knowledge implementation? Object-oriented programming was first promoted because the program objects could—should—model real world ‘objects’. The implementation seems to be something different. But the original impulse seems right.

Usability Design

Usability Design versus User Interface Design

Back just a few years ago, computers weren’t powerful enough to waste time with graphics. Screens weren’t capacious enough to waste space with blank areas. Times have changed.

Where before programmers could concentrate on providing raw functionality, now we have the resources to worry about how to present that functionality to make it easier to use and make it more pleasant to use.

However, making it easier to use and making it more pleasant to use are two different disciplines, one is usability, or user, design and the other is user interface design. And there is room for confusion on this terminology. Usability design tries to make the presentation suitable for the work and the workers. UI design is often an exercise in making screens more attractive, but not necessarily easier to work with. To make it easier to discuss the differences, I’ll write “usability” for the usability design work and “UI” for the presentation work.

UI designers are relatively common because, I’m being sarcastic here, they’re artists who are slumming. Usability designers are a breed of industrial designers and are much rarer, and more expensive. Usability designers have to work closely with the users and the programmers to get the flow of screens and procedures right.

Programmers sometimes dismiss UI designers as adding ‘eye candy’ that looks nice but has no substance. And indeed, some UI designers do little more than take an existing web page, adjust the field layouts, add some color and graphics and call it a day.

Now, you want UI designers. Making your product attractive is desirable, just don’t think that UI design is usability design or that a UI designer is a usability designer.

Examples of Usability Issues:

- Does the user need to scan the system for large amounts of information at once? Eg stock market brokers, call center operators, emergency dispatchers.  They do not have time to go scrolling around a bunch of screens, or even taking hands off whatever else they’re doing to punch a keyboard or scroll a mouse.

- Is the computer system central to their work, or peripheral?  That is, are they sitting there foresquare to the computer, or is the computer off to the side?

- Is the user intensely familar with the system or just a casual, or even a novice user? (Example: programmers tend to spend most of their time using their IDE—Integrated Development Environment, one piece of software of managing the project and coding code).

- Is the user interrupt driven (e.g. they take phone calls all day) or process driven (e.g. they have specific jobs they do.)

- Does the user work with one application or do they have to switch among several and draw from each to get a task done.

- Is the user a heads-down worker (they don’t even look at the screen to enter data) or a heads-up worker (they can see the prompts).

- Is the user better off not using a computer? Is a scanner or cell phone or ??? a better input/output device?

Speaking in pidgin

     The language of requirements is a pidgin language because it is a mixture of both user speak (in the progammer terminology, in the ‘domain language’) and techie talk. Now real pidgin languages arise in locations where people come together from different lands, they speak different languages but now, here, they need to communicate with each other. A mixed language develops, with borrowing from all the native languages. But pidgin languages use a simplified syntax (nobody bothers with rules about split infinitives) and is very practical. You don’t discuss philosophy in pidgin, you talk about buying and selling and getting boats loaded.

Now the language of requirements is a pidgin language in the sense that it borrows from both the user and programmer worlds and uses a simplified syntax and deals with practical matters, but it differs into important respects.

 

     First, you do try to express issues of great subtlety with it.

 

     Second, you can easily forget that you’re speaking a pidgin language because it looks and sounds a whole lot like English (or whatever it is you speak). You need to remind yourself every so often that you are not speaking English. There are enough of differences between user language and techie language for serious misunderstandings. Pidgin languages are not deep enough to support profound thoughts or subtle distinctions. 

Analysis/Synthesis

The analysis phase of a project is really part ‘analysis’ and part ’synthesis’. Analysis is breaking down what you know into its component parts. Into something small enough to get your arms around, simple enough to understand. Synthesis is putting what you know together, into a gestalt. When you’re talking to people, people tend to throw everything at you all at once: what they know, what they do, their feelings, their fears, their gripes, their wishes.

Your goal is to be able to break down their knowledge and figure out which is which. We need to compartmentalize this wealth and break them down into the bits that go into the requirement documents. But at the same time you need to building up your comprehensive picture of the company and the department and the operations. I suspect it would be better if you could do the synthesis first–understanding the whole–and then analysis, breaking it down into its components. But the learning process is too chaotic. And you won’t have near enough time to do it all, much less in a neat orderly way. So you’ll do both at once. But I think it helps for you to keep in mind that you are attempting to do both. That you are attempting to look in two contradictory directions, at the same time.

on getting more work

There is a story that sounds too good not to be true. The story goes that in the mainframe era IBM sold both computers and typewriters. And IBM made sure the secretaries of the IT bosses got the very best most attentive service on their typewriters.  So that when the IBM salesmen showed up to sell the latest computer they got shown right in.

Nowadays that iPods help sell iMacs is called the “halo” effect.  Not an entirely new concept.

I worked on a project that provided a fairly minor software application used by all the departments in the company.  It didn’t do much and it wasn’t a particularly slick product so that’s not my story here.  What it did do is make me do is go out to each department and actually talk to people.  In particular the office managers, secretaries and some of the bosses. 

Now most programmers do not have any reason to talk to users and we like it that way. I have the suspicion that most IT managers, being ex-programmers, don’t like to talk to users either.

But when I had to talk to real people they kept suggesting more and more work to do.  Little piddly stuff, things the IT department didn’t want to do, but in a season of downsizing, work is work. Sometimes I think that analysts need to pretend they are typewriter service guys.  Salesmen in sheeps clothing.  Real business analyst is a long term, intensive and pervasive activity and doesn’t really belong to a single project. Business analysis is about what is good for the company. It spans projects.  It spawns projects, projects are just point exercises along the way. But practicing analysis as a standalone endevour for one particular project looks kind of silly and superfluous. You should be unobtrusive and unobviously an analyst.  Like maybe the IT LAN administator who talks too much, or the IT training / help who doesn’t hide in the phone system but actaully walks around the building.  Someone who can get in and out and isn’t a threat to people.

The way we were

I’m working on a book on business analysis/systems analysis as done by non-technical types, by users, (any publishers out there interested in a query letter?) and as part of that, I have been wondering what happens to old programmers.

I have the impression most people do not work that long as programmers, they drop out after a few years. Morph into some other technical discipline or, mostly, get into another line of work altogether. So, unscientific survey time: if you were, or are still are, a programmer could you send me a note and let me know how long you were a programmer, if you changed jobs or careers, what made you switch, and how you feel about the change. Thanks!

Incrementalism

More on change to an existing system. Development projects spend about 80% of their time (I made the figure up) just to recreate the existing feature set. I would think that users would ask why the heck we waste so much money just to get back to the starting line, but I suspect the reason is they have no idea what we’re doing, why we’re doing it or even if it really needs to be done. There are a number of good reasons why we have to recreate the world every time, but more to the point we like our incompatible, disruptive technologies. It makes us feel creative. Personally, I got tired to writing the same basic business all the time.

Design v Requirements, part 1

I am working on the Great American Novel (joke. Does anybody still think in those terms, BTW?) And I use Scrivener, not Microsoft Word. Scrivener seems much more attuned to the process of writing. Which is a lot messier and more chaotic than Word hints at. But Scrivener is not perfect and I was thinking about how I would improve on it. I would keep all that it has already, in the form that it has it. Just add a feature here, a feature there. But this thought process led off onto issues for business analysis–which is always there in the back of my mind.

Two things: in programming it is often difficult to just add features to an existing software system. In this case because I don’t have the source code and can’t just glue new stuff onto the existing code. Another situation is where the existing system is so incredibly old (like in COBOL and CICS) your programmers won’t touch it and tell you it has to be rewritten from the ground up. Well, recreating all the old stuff is very difficult and expensive. For me, it isn’t worth it. Better to adapt myself to what Scrivener offers. And bend Scrivener to my evil intentions. 

Second, I got to thinking that if we were in this beginning systems analysis class and I told the students to write the requirements for a ‘word processor’ I could expect them to write the requirements for Word. Not because Word is the last word in word processors but because what we are used to is the foundation for what we desire. (What was the line in Silence of the Lambs? “We covet what we see…every day”?) We have to be careful about this constriction of vision when we practice business analysis.

More on both thoughts next time…

project budgeting

It would be nice if you way start a project by setting the budget limit: this what we can spend. But you know that just becomes the target.  The programmers want to spend it all.  And then some. It sets the size of the project, but usually the lower bound, not the upper limit.

But what if you started by saying you want an ROI target: this project needs to return $50m in increased annual revenue over its costs. I never seen this done. But you can see the effect, to get that much of an increase, you probably do not have small incremental fix in mind.  Or do you.  Consider, if the process generates $1B in revenue now, that is a 5% increase. But if the process generates $200m now, that’s a 25% increase.

More to the point, if the project looks like it’s going to cost $50m with $5m maintenance costs (the rule of thumb is annual maintenance costs are 10% of the development costs) with a ten year life span the project costs out at $100m so you should be looking for $60m in additional revenue. These figures are simplistic, but you can see that perspective shifted from ‘how much can we spend’ to ‘how much do we have to earn’ or if you will ‘how much do we have to produce?’ 

Because programmers think what we produce is a software product.  Once we deliver the code we’re done. We don’t think much about what the software has to produce, how much it has to earn for its living. We want to get programmers to think beyond code delivery.

I do not know any programmers who think this way.  Hopefully commercial programmers think this way. But I suspect many if not most of them have a Field of Dreams illusion, if you write it they will come. Just throw that software on the web and let people find it. Passive entreupeneirship. You can see why most dot comes fail.

The trouble with inhouse development is that the project managers shield the programmers from the nasty budget and scheduling process. They’ve been forced into this mode of operation, programmers don’t want to know (they just want to complain about it later). I suspect this mode of operation encourages the attitude. But if programming is going to grow up we programmers are going to have to learn the business.

How much documentation do you need?

How much documentation should you do? When you’re looking for something, why is it always in the last place you look?

Because you stop looking.

How much documentation do you have to write?  Just enough to be understood. And no more.

That is a simplistic statement of course.  It’s hard to know when you’re understood, unlike finding your keys. Being understood is not black and white. And this when you are talking to someone and they can tell you they do not understand or give you that blank look.  When you are writing and you get no feedback you cannot tell at all.  Even though or perhaps because I think of myself as a professional writer, I can guarantee you that if you rely on written documentation alone, you will write both too little and too much to be understood. To the degree needed. By anyone. 

Writing is hard.  You get that.

Reading is hard.  Nobody gets that. Unless we do not understand at all, we all tend to think reading is easy. I am studying Portuguese. I am at the point that when I read a sentence there are some words I ‘know’ the meaning of. But a word in one language is not a matter of subsituting the word, one for one, with another.  And the sentence structures are different.  The nuances, shadings of meaning and intend and allusion are different. It feels like looking through water or fog. And I realize that this is true not just for foreign languages, but for all forms of communication.