Category: software

Payroll systems, not yet a solved problem

I’m simultaneously unsurprised and shocked about this story about how SAP failed to deliver a payroll system that could properly handle 1300 employees, after the state of California spent $50 million on system development. We’ve been building payroll systems for decades now, and I believe that SAP is the largest software company on the planet that builds these kinds of systems.

This is a useful counterweight to Bertrand Meyer’s recent blog about how most of the software we interact with on a daily basis works well. He’s right, but we must also avoid falling prey to survivorship bias.

ESEM 2013 Industry Track CFP

The Call for Papers for the Industry Track of the International Symposium on Empirical Software Engineering and Measurement (ESEM 2013) is out. I’m serving as chair of the industry track this year.

If you’re reading this and you work in the software development world (and especially if you’re in the Baltimore/DC area), I encourage you to submit a paper that you think would be of interest to software engineering researchers or other developers.

I have a strong suspicion that the software engineering research community doesn’t have a good sense of the kinds of problems that software developers really face. What I’d really like to do with the industry track is bring professional developers and software engineering researchers together to talk about these sorts of problems.

Also, if you’re reading this and you live in the software world, I encourage you to check out what ESEM is about, even if you’re not interested in publishing a paper. This is a conference that’s focused on empirical study and measurement. If you ask me, every software engineering conference should be focused on empirical study. Because, you know, science.

Line by line

Through iTunes University , I’m following along in the lectures of a Yale course on modern American literature, authors like Hemingway, Faulkner and Fitzgerald. The professor talks about three registers of analysis: the macro, middle, and micro registers. At the micro register, the focus of the analysis is on things like the role of sensory information such as smell or sound. At the middle register, the focus of the analysis is on how authors of the time would experiment with narrative structure, such as the non-linear approach that Faulkner uses in The Sound and the Fury. At the macro register, the focus is on the larger historical context of the books. It’s only at the micro-level that you can do analysis by examining individual sentences. And, yet, the only way an author can write a book is to generate it by indvidual sentences.

We also talk about software at different levels of analysis, such as architecture for the higher levels, design patterns for the middle level, and lines of code at the micro level. There’s long been a yearning to be able to create new software by working at a higher level of abstraction. In today’s jargon, this is known as model-driven-development, where some kind of high-level graphical or textual model is created, and then is ultimately transformed into code. And this approach has found success in certain niches, such as Simulink, LabView, and Yahoo! Pipes.

For most applications, I suspect that the only way to write the software will continue to be the same as the only way to write novels: line by line.

Training is a dirty word

Two posts caught my eye this week. The first was Anil Dash’s The Blue Collar Coder, and the second was Greg Wilson’s Dark Matter, Public Health, and Scientific Computing. Anil wrote about high school students and Greg spoke about scientists, but ultimately they’re both about teaching computer skills to people without a formal background in computing. In other words, training.

In the hierarchy of academia, training is pretty firmly at the bottom. Education at least gets some lip service, being the primary mission of the university and all. But training is a base, vulgar activity. And it’s a real shame, because the problems that Anil and Greg are trying to address are important ones that need solving. Help will need to come from somewhere else.

When something you believe is false

When you’re programming, and the program you’re working on behaves in some way you don’t expect, then by definition there’s some assumption you’ve made about the system that’s incorrect.
Today I was working on adding some fields to a Django admin interface, and I got an unexpected error message when I tried to create a new object in the admin interface and save it. The code was very similar to other code I had previously written that already worked, so I tried to figure out what was wrong by identifying the difference.

The important difference I couldn’t see was that the name of a variable was the source of the problem. In this particular case, the field name (image) was colliding with the field name in a grandparent class, which caused the error to occur. I hadn’t considered that the name of the variable was a meaningful difference that could cause a problem, until I did a search on Stack Overflow and found someone who encountered a similar problem.

This is one of the hardest parts of programming: being able to systematically test your assumptions until you discover which of your current beliefs are false.