I’m back at university, in an effort to force myself to knuckle down and get through the pain of learning Java. It’s been 16 years since I was last there, and here are a few of the things I’ve learned so far -

I’ve learned about the syllabus
Despite the move to Java, very little has changed in the overall teaching approach in 16 years. I’ve heard from another source that someone in my position 15 years ago may have been saying the same thing.

I’ve learned something about gold-plating
University seems to reward you for adding extra features. This doesn’t seem to happen in the business world.

A couple of years ago, I had a graduate developer assigned to my test team to help extend a test tool that I had written. He seemed overly focused on wanting to build a GUI for my tool, when a simple command-line interface was all that was needed to solve our problem. Similarly, with a user base of three, robust error handling was something we could live without. After a couple of semesters of university assignments, I think I understand why this was the case.

I’ve learned something about testing
Lecturers are mostly not embracing some of the not-so-recent trends. I’ve found JUnit tests a boon on assignments where we are incrementally adding new features. Having these tests as I implement existing functions using newly-learned language features, or to add new functionality for new assignments makes things much less stressful. Implement a test per requirement also helps to make sure I get all the marks for the assignment as well. When I suggested a student learn JUnit rather than passing parameters to their classes manually via a GUI interface, lecturers seemed against it, despite the many practical (and career) benefits.

I’ve learned something about learning
University seems really keen to have students build GUIs on everything. Now, GUI building seems like a reasonably complex thing, object-wise. As a beginner, figuring out how to model the domain is hard enough without being forced to put a hacky user interface on top of it.

Learning to model a domain doesn’t start with modelling the user interface.

I’m sure there are more progressive courses out there. I’m just surprised that the take-up of things that are of much benefit to beginning programmers is coming along so slowly. But then we are always making a tradeoff between what we can easily teach and what’s worth teaching. Just look at tester certification.

Matt Heusser’s recent blog entry on Tester/Developer communications prompted me to comment on the dreams of agile projects and tester heaven.

Now, I’ve been tempted to have that conversation, but the conversations I have had instead are much more along these lines:

Me: “Hey dev guy, here’s 20 years of accumulated knowledge describing why the testing approach you are about to take is not going to solve your problem, cost a lot of money, and waste a lot of time”.
Developer: “That’s nice, but we’re going to do it anyway”.

Two months later:

Me: “So, how’d that test approach work for you?”
Developer: “Oh, it completely sucked and was unmaintainable”.

Now, these developers are not stupid people, but it’s difficult for me to understand how things get to this point.

Or at least, it was until recently. Most agile development projects are much like Toyotism (or Lean, if you prefer). Better than how things were in the past, but not fundamentally changing the nature of work. Just as work in manufacturing is still hard, repetitive and largely about lines, so we easily fall into our old factory-style patterns. I believe this is at the heart of Brian Marick’s statement on the current state of Agile project experiences: ‘Whereas the number of people new to Agile who describe their project as “the best project I’ve ever worked on” seems to be declining, and we believe work should be joyful.’

Parallel lines of software development, with variable development and testing tasks performed serially end up being just as unpleasant as the old ways. Except now the moment your testing task takes longer than the development task in the queue behind you, someone’s screaming about the tester backlog.

Of course, it doesn’t have to be this way, but there’s very little incentive for the guy with the upstream work to contribute to solving it. They’re not the ones feeling the pressure. And once those pesky testers are gone, the whole thing actually appears to work much more smoothly. After all, what’s smoother than an assembly line with a single step?

Hint: The last line *is* the answer. But the devil is in the details of what comprises a ’step’. And what Matt describes is a step toward the solution as well.

Stay tuned.

Spare a thought for the people that recently hired my friend Steve, as you read about his latest job (in the second last paragraph):

http://cramdogg.blogspot.com/2007/02/watching-printer-101.html

After an email exchange with Matt Heusser, Matt has posted my comments on how our work tools sometimes influence our behaviour on projects. That’s because these work tools are based on models of how someone believe software should be developed. Perhaps more importantly, the tools that I’ve seen are usually designed to ensure that the team conforms to a process, not to ensure that the right things have been done.

The tool that I feel most strongly influenced the agile process in a former employer, is the workflow tool. Workflow tools are typically linear flow tools. I believe that the use of these kinds of tools (in our case, JIRA, but you can substitute most bug tracking tools if you like,) strongly reinforced a linear model of software development. I’m not aware of any tools that don’t model software development this way, but am quite happy to be shown to be incorrect.

If you don’t want your team throwing their work “over the wall”, check that your tools model development the way you think it should be done.

Jon Eaves was blogging about problems related to development goals not aligning with business objectives and it resounded with some thoughts I had been having on company values.

In addition to goal alignment, I’m thinking at the moment that alignment of values is equally important, or at the very least it helps when the true values of the company are clearly stated. Goals tell us where we want to go. Values help us make decisions along the way.

While individual values may vary from the company’s, by being conscious of our own goals and that of our employer’s, we can discuss the differences, or at least see just how wide the gap is between one’s own values and one’s employer. I think this is a good starting point.

I overheard the following sentence from a project manager, accompanied by shock and outrage:

“Two *resources* didn’t turn up this morning!”

I believe the word they were looking for is “people”.