whither software development

Read in another blog that the era of business application programming is fading. I should have gotten the book out five years ago! But it’s usually the standard reason for the decline: companies are switching to standardized off-the-shelf implementations. A few years ago it was big enterprise packages, now it’s the cloud. So while I do agree that business application programming is probably in decline (but does anybody collect hard statistics?) a bit of skepticism, the reports seem often driven by marketing hopes and wishes. What we need is a development regime to address the needs of small outfits that need some aspect of their business automated but who can’t afford the costs, can’t afford to eat the costs of failed/lame projects (risk!) or pay the ongoing maintenance of our current way of programming. Part of the issue is not just the programming, I have the sneaking suspicion more and more programming is DIY and under the radar, but I worry that the larger issues are not ignored, they aren’t even visible by the unwary. Security, privacy, liability, legal, regulatory, audit, recovery, backup and restore, and so on. Something that a project manager (ought) to know about. It’s not about does this programming language handle this kind of bit nibbling or not. But admittedly, I haven’t been looking around. Are there freelance project managers out there helping small business?

one rant about language

 

Books on analysis tell the programmer that use cases should be in the domain experts language. But where does the programmer learn that domain language? If it were in French wouldn’t we want to suggest the programmers learn French, like ASAP?

It doesn’t help that a system often has multiple user groups, each with their own language. Different user groups may need access to the same functions so there should be multiple cases of use. And each of them in “English” if in different domain languages. It might easier if the language were more obviously distinct, like French and German rather than accountingese and warehousese.

On the other side, we draw use case diagrams and don’t bother to teach all the users how to read them. How can we get feedback and fixes? I know people who are intimidated by the diagrams making it all the harder to discuss the content. And the software needed to display it (yeah, I know, just print it) is often so expensive, we’re reluctant to spend a seat license for a user copy, so the users have to come to us, to our machines to see the diagram, the psychological message being that this is our system, not theirs.

 

Programming tools for users

I have heard that in the olden days, users wrote their own computer programs. Now users were probably scientists and engineers and may have been intimidated by assembly language or whatever was available, but the advantage of user written software is that one doesn’t have to explain what one needs to a second person, the programmer.

Jump forward a few decades. The meat and potatoes CRUD applications of business computing are pretty much all written what we want now are applications that explore direct physical sensors, processes useful to knowledge workers, analytical tools to explore massive data stores and probably others. Take one, knowledge worker processes. It’s hard to explain how we think…

 

What we need are new programming tools. One for use by non-programmers to express their requirements. That can then be manipulated by the designers to explore how best to express the requirements. That can then be enhanced by programmers to create the best implementation of that design. Tools that are useful for different practitioners at different stages of the process and that know how to hand off the nascent product to each other (in both directions, given the iterative nature of software development).

Current programming languages seem to concentrate on that last phase. That maybe fine for programmers, that’s what we like to do. But perhaps we need to step back and look at the big picture…

 

Notice that position of design between requirements and programming. In design we need to be able to explore several designs, not just one, and to compare how issues get resolved, or not, among the various designs. Even as requirements, designs, and iterated code evolve.

 

Street scenes

Matthew Frederick in “101 Things I Learned in Architecture School” learned that an ‘urban infill building should be designed to come out to the prevailing line of the street. (item 91. The MIT Press, Cambridge Massachusetts, c 2007). I think this has an association for systems analysis. We programmers tend to think of the software as a thing in itself. And as many programmers on a project never even see the user space, we don’t have any idea of a street line, we don’t know what other software people use. We don’t what their work is, what other physical systems they use. I know when I have to switch from one system to another, the transition can be quite jarring, what must it feel like for users who may have to switch constantly amongst applications in a work day, within the context of a single action?

This is not to argue that we should write all applications with the ‘same’ interface, workflow, architecture, parti (organizing idea). Given the mish-mash of interfaces out there now and the age of some applications, that might be hard to phase into. Also, I would fear the thoughtless requirements to standardize on an inadequate standard (for example, I don’t like forcing web-like interfaces on in-house data entry systems).

in dreams…

I realized last night that I have a new dream setting. I have dreams that recur in the same place. There used to be a whole town where I would (as a younger self) skateboard and I only realized it when I skated into a different neighborhood. And oddly enough, once that happened, I haven’t been back.

Last night I realized I’ve been dreaming about an apartment building with trellises and tall skinny trees in light well gardens. And some odd people. I think the people recur from dream to dream too but that I’m not so sure.

But I was wondering, does everyone have these alternate dreamscape worlds they habitually return to?

parti

I am reading Matthew Frederick’s “101 Things I Learned in Architecture School” because I’m a bit of a sucker for architecture as an analog for the systems development process. And not just because of Christopher Alexander and “A Pattern Language” though that didn’t hurt. Mr. Frederick introduced me to the term parti as the organizing idea of a building. (The book isn’t paginated, but it’s item 15.) I had never heard of the term before but it resonates. In systems development we talk about an architecture but it in practice it means deciding on–or defaulting on–client-server or multi-tier structures to distribute the software.

I was reminded more of a project I worked on for an intra-company forms messengering system. I used a certain email system as the platform. The project failed miserably. It wasn’t the fault of the email system, at least one of the problems was I hadn’t sat down and throught about the governing nature of the system. It wasn’t email.

In systems analysis it helps to consider the proposed system from as many different angles as possible. Different users and other interested parties. As a static domain classes and then as dynamic processes, and so on. And so, too perhaps, it’s parti.

Maps

Overheard in Bird and Beckett, a woman looking for maps, nobody sells them anymore. The sales person commiserates, there are no map stores anymore (I’m thinking, Rand Mcnalley in North Beach is long gone). And what of it? Don’t I just use Google maps myself?

Except maps aren’t just for finding your way from here to there. In writing the question is whether you should have an outline before you start writing and if so, how detailed. One author counseled that you want a map of the territory ahead, not the exact route. Because writing isn’t that straight forward, but you still need to have a sense of where you’re going and the territory ahead.

But also maps are needful for what isn’t there. At one extreme, those ancient maps that ‘here be monsters’ or closer to our own eras, with helpful cartoon illustrations of wonderous things along the way. Bill Buxton in his book on design wrote “You have to leave big enough holes to let imagination come into play.”

Google maps look too complete, too stolid. Now, I am not adventurous by nature, I’m just a bookworm, maybe Google maps are still enough to stir the blood and quicken the heart of adventurous souls—Samarkand and Uttar Predesh, Istanbul, Prague, Budapesh, the Escalante. I always expect that software hidden behind the Google maps will keep it updated, fill in the mysterious. A paper map is different, somehow they beckon, ask me to fill in the blanks.

The UI is the message

I suspect programmers tend to design user interfaces from the inside out. That is, first here is the function, therefore the UI needs to look like this to express the function. Form follows function. Obvious.

Two concerns. First is that kind of obvious function-oriented interface can be hard to explain. I think that programmers should be required to train they users. A form of eating your own dogfood. If you can’t explain how to use the system maybe there’s something wrong with it. The functionality may be all right but a system is more than functionality.

The second concern is even more nebulous: the nagging thought that Marshall McLuhan’s saying that the ‘medium is the message’ has some truth for software systems as well. That our programmers assumption that the function is all important and that the UI design is just more eye candy is wrong. Or mis-proportioned.

Reading the center column



I had been looking at a science news aggregator site for several days when  realized I had only read a third of the news. The news was displayed in three columns. From other website layouts, I was used to the left and right columns being advertising, so I never looked at the left or right columns of this site either, even though they didn’t carry any ads and I was just ignoring most of the news.

Does this mean that you have to take into consideration the design—good and bad and coincidental—of other sites in your designs?

I don’t care a whole lot about web design, though. But I suspect this applies as well to system design. Particularly how we assume a system will flow. What kinds of functions and services ought to exist, how we find them, how we can incorporate them into our work process.

Imagine

In the old days we mostly automated manual procedures, so requirements and specifications were straight forward. Nowadays hardware and software is so much more capable, that what you want is to devise a way to do things you couldn’t imagine doing manually. And there’s the rub…how to you specify what you can’t imagine?