Translating user requirements to code can be hard

Back when I was working as a professional programmer (my job title was “Systems Analyst”), I would attend meetings with my supervisor to gather user requirements. Sometimes, I’m not required at the meeting, but typically, my supervisor needed to know if something was technically feasible. That’s where I came in.

At those meetings, which could be 3 to 4 hours long, I would gather notes. (Once I had to attend a whole-day event. I had to look at it as “I learnt more about my users’ business” rather than “I wasted an entire day”. I’ll tell you about it some other time…) Sometimes, these notes weren’t written because my users specifically told me about it. It’s just that I took note of potential technical limitations and problems that my users didn’t see.

For example, they might draw a sketch of the user interface on the whiteboard and I’d copy it if necessary. Then I took notes on the possible internal code structure if necessary.

The hardest kinds of user requirement gathering are the super-really-obvious ones. Even to you.

The hardest user requirement I’ve ever been given was an Excel spreadsheet. That’s it. The user basically said, “I want you to give me a report that looks like this Excel file.” Implicit requirement was that the file data reflect current database data.

I had to hunt for the source of the data (which database?). Other than that, I had to figure out how to create the Excel spreadsheet layout based on the given sample file.

You can’t really ask what settings the particular spreadsheet cell has, because the user would say “It’s there! In the file! What do you mean how did I set it?” All the styling/layout requirements was already in the Excel file.

I’m starting a course!

All this is really a long way to tell you that I’m starting a course teaching about Open XML spreadsheets, using the Open XML SDK as part of the tool kit.

“But there are lots of resources online about Open XML! And they’re free!”

I know. They tell you how to do a specific task, such as setting a cell value or “This is how to read an Open XML file” and so on. But they don’t tell you why you should do it.

I’ve got a couple of customers (who bought my Open XML spreadsheet reference) asking me, “How do you set this style?”. Then they show me a screenshot or the actual Excel file, and it’s like this complicated (or elegantly professional, depending on your perspective) mess of a jumble of cells with background colours and borders and OMG is that a merged cell?! (One programmer sent me the actual file he’s to simulate, and I felt really sorry for him…)

So in addition to teaching you about the Open XML parts and code and stuff, I’ll also teach you how to translate a given Open XML spreadsheet into code that generates that spreadsheet.

Tentative price is USD 30 for the whole course. The course is about 8 to 10 lessons, with each lesson given weekly. I’ve a rough outline of the course curriculum, but I’m open to suggestions at this point (contact me or leave a comment). It should be up in the next couple of weeks.