There’s an animated video making its way around the legal blogosphere in which a cynical older lawyer tries to convince an idealistic prospective law student not to go to law school. As a non-lawyer, I’m probably missing half the jokes, but it’s still pretty funny.
I was more fascinated, however, by the web site used to create the video, xtranormal.com, which provides tools for anyone to make a video in a similar style. Once you register for a free account, you can use a simple interface to create the shooting script. You can change the characters and setting, and you can annotate the script with facial expressions, animations, sound effects, and changes in camera angle. When you’re ready to see what you created, the site can generate a low-res version of the video for you to preview. Once you’ve got something you like, you can re-render a high-quality version for downloading and publication.
I had to give this a try. In keeping with the theme of the first video, I made it about what I do for a living. I don’t know what the job market is like for a beginning software developer, but I’m not nearly as cynical about my job as these lawyers are about theirs. Still, there are some annoying surprises for people just out of school. After a few years, the surprise factor is gone, and only the annoyance remains.
So here’s my video of a conversation in which Mark, a software engineer, finds out about his next software project from Ted, the boss. My clients are too smart to waste my time and their money this way, but back when I was an employee at a mid-size corporation, I had a depressing number of conversations like this. You see, a lot of people launch software projects with almost no thought to the details, except for one curiously specific requirement…
Perhaps there’s a cautionary tale in that video.
What is needed (in theory) is either a programmer who is trained in business, or a business person trained in programming to be a systems manager. The logic behind business schools taking over IT teaching in the 90’s was to create a middle-man for just such circumstances, while the CS departments were to concentrate on programming. Hence the IT business systems designer was born.
The engineering field was having such problems in the 80’s. They were looking for engineers who would get a degree in design, or designers who would go get an engineering degree to act as a translator and project manager.
Ultimately, most companies got rid of both their designers and their engineers and replaced them with high school grads who were good at CAD. (I first noticed this when many of my part-time undergraduate students identified themselves as engineers. At first I didn’t believe them, then slowly realized that they were the new design engineers of our time.)
Right now companies don’t want to pay for a middle man, so they want a programmer who knows business, or a businessman who knows how to program to do the entire system from concept to implementation all in one person.
I wonder, if the promise of 5GL were fulfilled as once envisioned by the field, if companies would replace system designers and programmers with high school grads who knew how to run a computer aided business system design package?
Maybe that’s why 5GL never went beyond hype. There’s an evil conspiracy of programmers who are preventing any such systems from coming to market.
So, the big question in all this is, why haven’t you invited me to any of the conspiracy meetings?
The point of the video was actually somewhat more mundane. In some software projects, the customer (external or internal) has no idea what they need or how it might work, but they can tell you exactly when they need it.
At a previous job, I mentioned this phenomenon while chatting with a department manager who had just started to take on some software development projects, and she immediately read me an email she had just received. It said something like, “We need to schedule a meeting to define requirements for the Mumblefritz project because it has to be finished by September 30.” They had no idea what it was supposed to do–as evidenced by the need to define requirements–but they didn’t want to deliver it late.
(This happened a lot with our government contracts. We got money to perform a task and we had to stop billing the project when the fiscal year ended, so we might not be sure what we had to do, but we knew when it had to stop.)
At least for small projects, the problems you raise are addressed somewhat by changes to the requirements discovery activities. For example, a lot of money and effort has gone into making software projects more agile–more able to respond to changes in the requirements. This allows developers to build a partial solution based on partial requirements and then show it to the end users for feedback. With a concrete prototype to talk about, end users and programmers can have more fruitful discussions. In the past, this was a road to budget ruin, but the cost of rework is now a lot lower, which makes this approach more appealing.
Perhaps it’s wishful thinking on my part, but I don’t think development of 5GL technology (whatever that is) will eliminate programmers. If we develop magic 5GL tools that make it 100 times easier to solve a certain class of business computing problem, that will also make it possible to attack problems that are 100 times more complex. which is what the business end users will soon demand. That increased complexity will create the need for 5GL experts with the training and experience to handle such large and tricky projects. We will call them programmers.
(I suspect engineering complexity probably doesn’t scale up this way because engineering must ultimately lead to tangible things in the real world that face real limitations. We are less constrained by reality here in cyberspace.)
I’ve been reading predictions of The End Of Programming since the early 1980s, and it always turns out this way. The newer, better tools require people called programmers to get the most out of them.
By the way, there is no conspiracy. Who told you there was? I want names.
As a former programmer, I thought this was hilarious because of its veracity. Although in my case, I worked in a research lab where I understood the subject domain and could often generate the specifications myself so it didn’t come up often, at times people wanted a program written to “solve their problem”, but didn’t really know what the “problem” was. And of course they needed it yesterday.
Even programmers, though, succumb to assuming what they want to happen is going to be the result of the code they write, not what really happens (one of the nice aspects of programming is there is no arguing whose at fault – it’s always the programmer’s fault when it comes to the coding), reminding me of a quote by Maurice Wilkes shown in his Wikipedia entry:
“It was on one of my journeys between the EDSAC room and the punching equipment that ‘hesitating at the angle of the stairs’ the realization came over me with full force that a good part of the remainder of my life was going to be spent finding errors in my own programs.”
I guess this just underscores that when one writes a program or routine, the programmer has to know exactly what to do for each and every possibility that can arise.