White Collar IT Revolution

I went to the hospital today. There was a queue of people waiting. Some simply wanted to get a stamp in a prescription. Others merely wanted to schedule an appointment.

The government clerical workers, all women, toiled the best they could. I could see the grim determination pictured in their faces. I could see the speed they were processing each request. They were fighting, with a mix of one software generation old information technology systems, and reams of paper. They were stressed to the max, as were the people waiting. I was sad at this state of affairs, because as a software engineer, I know we can do better. All these tasks can be automated by computers, done via the web by users and health care professionals in real-time. No waiting. No stress.

When people say they fear loss of jobs like these I say:
To hell with those jobs! They are dehumanizing. People should not be treated like cogs in a machine.

Then I had a flashback. I felt like I was watching a modern version of a telephone switchboard operator.

Some things did give me comfort. The smile of a beautiful girl, the tranquility of a woman carrying a child, the glorious beach.

Then I had another flashback: one hospital I went to was already providing blood analysis results via an Intranet application in PHP. It was an incomplete application, probably a hack, but already it was giving health care professionals valuable real time feedback. In another, a Java program empowered the doctor to schedule appointments. In yet another hospital, prescriptions were directly provided by the information system from the doctor to the patient.

As our ancestors the Romans, that people of great engineers would say:

Adde parvum parvo magnus acervus erit
- Add little to little and there will be a big pile.

Practices of an Agile Developer : Working in the Real World

Summer has arrived. The local telephone monopoly has succeeded, for the second time in weeks, in cutting the lines to the neighborhood without warning. I was without Internet access and little chance to work. This provided good motivation to finally put my hands on some of the books lying around here. I wish to speak of a book, which I found very interesting indeed.

Practices of an Agile Developer : Working in the Real World
by Venkat Subramaniam and Andy Hunt

This book has a set of rules, or best practices, for a seasoned programmer or project leader wishing to work according to agile methods. The authors are experienced in the matter. Andy Hunt had previously been co-author of The Pragmatic Programmer: From Journeyman to Master. This book is chock full of good sense, resonates well with my experience, gives examples and practical advices about how to solve software development issues. Not only coding, but design, team and client communication issues as well. I believe it has good ideas for all of us interested in software development and deserves nothing less but praise. It is solid quality prose throughout. Sage advice condensed in a small and easy to read book.

To better provide you with a feel for it, here are some nuggets:

Quick Fixes Become Quicksand
A former client of Andy’s had this very problem. None of the developers or architects understood the underlying data model of their domain, and over the course of several years the code base became littered with thousands of +1 and -1 corrections. Trying to add features or fix bugs in that mess was a hair-pulling nightmare (and indeed, many of the developers had gone bald by then). But like most catastrophes, it didn’t get like that all at once. Instead, it happened one quick fix at a time. Each quick fix—which ignored the pervasive, underlying problem—added up to a swamp-like morass of quicksand that eventually sucked the life out of the project.

Criticize Ideas, Not People
You’ve probably seen design discussions that get out of hand and become emotionally charged—decisions get made based on whose idea it was, not on the merits of the ideas themselves. We’ve been in meetings like that, and they aren’t pleasant. But it’s only natural. When Lee presents a new design, it’s easiest to say, “That’s stupid” (with the clear implication that Lee is stupid as well). It takes a little more effort to elaborate, “That’s stupid; you forgot to make it thread-safe.” And it actually takes real effort and thought to say the far more appropriate, “Thanks, Lee. But I’m curious, what will happen when two users log on at the same time?”

Damn the Torpedoes, Go Ahead
Courage doesn’t feel very comfortable, certainly not ahead of time. But it’s often the only way to remove obstacles that will just grow worse over time, and you’ll feel relief instead of increasing dread.

Keep Up with Change
“There is nothing permanent except change,” said Heraclitus. That has been true throughout history, but it’s especially true now. You’re in an exciting and ever-changing field. If you graduated with a degree in computer science or some related professional field and thought you were all done with learning, you were dead wrong.
...
Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.

Invest in Your Team
Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).

Know When to Unlearn
As technology marches on, things that used to be of paramount importance fall by the wayside. Not only aren’t they useful anymore, they can actually harm your effectiveness. When Andy was first programming, memory overlays were a big deal. You often couldn’t fit the whole program in main memory (48KB or so) at a time, so you had to split your program into chunks. When one chunk was swapped in, some chunk had to be swapped out, and you couldn’t call functions on one chunk from the other.
...
We’ve seen ten man-year J2EE projects go down in flames, only to be replaced with a month-long hack in PHP that delivers most of the features. Growing interest in languages such as PHP and web frameworks like Ruby on Rails show that developers are catching on that the old ways might not be cutting it anymore.
...
Old habits are hard to break and even harder to notice. The first step to unlearning is to realize that you’re using an outdated approach. That’s the hardest part. The other hardest part is actually letting go. Mental models and patterns of thought are built and refined at great cost over many years. One doesn’t discard them lightly. And it’s not that you really want to discard them completely, either. The previous memory overlay example is just a special case of manually maintaining a working set of items from a larger cache. The technique hasn’t gone away, although that implementation of it has. You don’t want to drill into the brain and snip all those dendrites off. Instead, you want to use older knowledge in context. Reinvent it and reuse it where applicable, but make sure you don’t drag along old habits just out of, well, habit.

It had not come to my mind before reading the book, but even at 29 years of age, I need to learn how to unlearn. I made a personal effort to learn languages such as Java, C#, Python and PHP, not taught to me at college, but was still editing code with Vim. Since changing to IDEs with refactoring support, something which did not exist at graduation time as well, I can do much more in less time.