Communications of the ACM
Sensibles of Software Engineering, 1 and 2
A former classmate of mine, who went into construction and mechanical engineering when I chose computer science, told me once that in one of the last lectures, the lead professor said to his class that over the years they had learned many sophisticated concepts and techniques, but in the end if they remember just one thing it should be this: if the equations show that the building is moving up from the earth, not sinking down into the earth, the equations are wrong and they should start again.
A former software development colleague similarly told me that the one thing he remembered from his CS curriculum is that one should do configuration management.
Such down-to-earth rules can be important. I call them "sensibles" and I have a feeling that we tend to neglect them in teaching software engineering. (Here I must say that I am writing this column for the few remaining people who think that it is still useful to teach software engineering, not just machine learning and artificial general intelligence.) When we do teach the discipline we cover sophisticated concepts, as we should; but when I see how software is actually produced and released, I do wonder whether the authors have ever been taught the sensibles.
The sensibles are not sophisticated; they are good, practical injunctions, as exist in all disciplines. ("Before turning on the electrical installation, make sure it is grounded.") Today I am mentioning two of them. Do not expect any intellectually challenging new concept; they are both common-sense, but common sense that (in my experience at least) gets violated again and again. I am not aware of software engineering textbooks that mention them or, for that matter, of standards of good practices described over hundreds of pages, such as CMMI, that include them either. (I have not read all software engineering textbooks or process model descriptions, so please correct me if I missed such mentions.)
I may come back with more sensibles in the future, and of course will be grateful for readers' suggestions about their own sensibles.
1. Do not retire the old system yet.
A system was in place for months and years; it was limited in its scope, users had lots of suggestions and complaints, but somehow it worked. Now you have spent considerable effort building a shining new version. It is so much better! Next Monday we switch.
Not so fast. Things can go wrong and often do. (Modern techniques of continuous integration and development of Web applications can make things even worse. See here for a case that befell me.) In fact, the replacement system seldom, in my experience, works quite right the first time.
So: when you switch, be prepared to switch back. Do not retire the old system; keep it active. Only after a suitable period of smooth operation of the new version can you give the old version its well-deserved rest.
It is all so obvious, and so frequently disregarded. Please remind bright-eyed newcomers (bright-eyed about the beautiful system they just concocted to replace the rusty old one) that they, too, are unlikely to have gotten everything right the first time around.
2. Eat your own dog food.
The next principle is so well-known that it has its own Wikipedia entry, but that does not mean people remember it. What it says in its slightly vulgar terms is that the only real way to understand users need is to be a user, or become one.
The EiffelStudio development environment is written in Eiffel and developed with EiffelStudio (the previous version). The EiffelStudio code uses much of the technology, but not all. If you look at the various parts of this complex and sophisticated construction, you will definitely notice that the parts that developers actually use are more refined, for example in their user interface, than the others. This situation (regardless of whether we regret it) is typical of the eat-your-own-dog-food phenomenon. When you start to use facilities and have control over them, you will discover hindrances, large or small, and fix them before they have had the time to hit any outside users. 'Eating your own dog food' is the best way to ensure that functionality is right not only in general and in principle, but in the details, and is adapted to the practical needs and preferences of real people.
How does this principle transpose to a tool meant for a totally different category of users (unlike EiffelStudio, a tool for programmers developed by programmers), such as, say, software for dentists? Well, you have to become a dentist. Someone from the development team should have the courage and humility to learn for a few weeks how dentists work (without actually getting anywhere close to someone's teeth).
Unless you make that effort, your system will not be really usable. I have seen too many times how developers imagine users going through complicated procedures. They seem legitimate to the developers because they use an inside perspective (this is how things are organized, hence you should go through that sequence of steps) instead of the outside perspective (I need all the time to do this and that, and I am not going to use more than two clicks to get my result).
Do not retire the old system yet; eat your own dog food. These are two of my software-engineering sensibles. What are yours?
Bertrand Meyer is a professor and Provost at the Constructor Institute (Schaffhausen, Switzerland) and chief technology officer of Eiffel Software (Goleta, CA).
No entries found