swag

A little surprise to start off the work year. I guess while I was on vacation they gave some stuff to everyone for end of year. There was still some left so I went up to where HR had it and got mine.

It was a soccer theme with company logo gear from umbro. There was a carry bag with a soccer ball to inflate, a ball cap, and a long sleeve soccer shirt. It looks fairly nice.

In high tech the flow of swag is often a fairly good indicator of how the company is doing. At least it was pretty accurate back with SupportSoft and Core Networks. When the company is doing well the swag can flow pretty fast and thick with t-shirts, baseball caps, golf shirts, knickknacks, mouse pads, fridge magnets, pens, rugby shirts, jackets, free meals, etc. When the company is not doing well then you can tell because the flow of swag dries right up.

User Stories Applied

I just finished reading the book User Stories Applied. It was interesting. A co-worker lent me the book and suggested I read it. I can't remember the last time I read a work related book on my own. It's been a long time. I guess my interests outside of work are more, well, "interesting" than studying up further on what I do during the daytime to get paid.

It's good for me to get more of a grasp on what all this agile stuff I hear about all the time is about. I still don't really get it. As I read through User Stories Applied I kept thinking to myself did you actually build real software this way? Although the author is careful to consistently back up his talk with examples from real projects. So it apparently has been used on real projects and isn't just some academic thought experiment.

I guess it's hard to get comfortable with something that is such a departure from the projects I've always worked on. Still over the years people have attempted to introduce some of the concepts of agile into the software development project management. I think that's the thing with agile among established companies. We want to pick and choose the more interesting and useful aspects without going whole hog and having say 2 programmers to a workstation.

For example iterative development with feedback is good. We've all known from hard experience for a long time that the "late and large" integration at the very end of a software project is a bad way to go. So we try to build earlier and keep it in a usable working state where people outside the team can use it and give feedback. That said we were using milestones back at PRIOR on the CMS SB3 project in 1998.

One thing that really struck me was pretty much every chapter kept going on about this individual called the "customer". The customer writes the user stories (NOT the programmers!). The customer writes the acceptance tests (hmmm). The customer provides feedback between iterations and determines which stories are to be done in each sprint. This is a certainly a departure from the past with that level of customer involvement. In my experience I'm reading this and thinking, Who is this customer? I don't recall seeing him around very much in my 12 years in the cubes.

So that's something that's important and different. Agile isn't some internal fad or thing that the programmers do on their own that is opaque to everyone else. The customers have to be more involved. That involves organizational change. If the organizational change doesn't happen and it ends up being the programmers writing the stories and the acceptance tests and planning the sprints, etc. then agile probably won't be very successful.

It was a good book. I did learn a lot more about agile. It's part of the Kent Beck signature series. I think I've grasped enough for now and I'm not planning to read the rest of that Beck series. I've got some other books outside of work related lined up to read.


I remember back at TUNS in the software engineering course. The prof did a series on 4GL and code generators. He showed us this demo of some TI system called IAF or something like that. After you set up all of the screens and described the data and workflows it set about generating C code at a rate of about 100,000 lines and hour.

The prof made an interesting observation. IAF was very good at the traditional integrated order entry - inventory - shipping problem for mid to large manufacturing companies. That one specific scenario. However you wouldn't build a compiler with IAF. You wouldn't build IAF itself using IAF.

I think that would also apply to user stories as well. For example I wouldn't specify the emergency shutdown software for a nuclear power plant using user stories. I wouldn't design air traffic control software with user stories. I think user stories and agile may be useful in certain categories of software development; and inappropriate for others.

Software development is a large and diverse space. Internal IT department. Systems integrators. Shrink wrap software installed at a remote site. Web apps running off one big live website. Within this large space there are probably some situations where user stories and agile work well.

Colour printing in the office

We put in some new printers a little while ago at the office. Usually that's nothing special. Stuff doesn't work for a couple of hours while they get the IP and printer name and such set up then business as usual.

But it was a bit different this time. We now have colour printing in the office for the first time. And it's great. I like to print code and it's great being able to get the same printout as is on my screen. So I'm really enjoying it.

It makes sense to have colour printing. Our monitors are in colour, powerpoints are colour, so you would logically expect to print in the same colour as you get on the screen. Plus we've had colour printing in our cheap home printers as completely standard for like 10 years now.

So why has it taken so long for colour printing to arrive in the office. Some history might be useful here. Back around 1997-1998 at PRIOR Data there was this Y2K project for the military. PRIOR was providing office space and some services and staff to a group who were doing this huge Y2K readiness project for the military, checking the readiness of all kinds of stuff like elevator systems and whatever else they could think of that might fail.

They were mostly downstairs from the main PRIOR office on Spring Garden Road. As part of Y2K they were producing a lot of documentation of course. And there was a rumour they had this special printer called 'Howe' that was a big HP machine that cost $27,000. And it had double sided printing.

It made sense for them for their project and the amount of documents they had to produce. For the rest of us upstairs we asked the sysadmin once in a while about double sided printing. The response was usually something like "that's really expensive; we would need to install special hardware kits on our printers; we would need to install special drivers on everyone's PCs". There was a perception that double sided printing was an exotic thing that was too difficult and expensive to make widely available.

But by 2001 when I joined Core it was just there, completely standard, even on the cheap Lexmark office printers. Double sided printing was just something that came out on the next generation of printers and it didn't cost any more when getting new printers to get double sided [although you saved a fortune on printer paper] so that was that. And we've had double sided without thinking about it for years now.

For a long time colour printing was where double sided was around 1997-1998. People were suspicious that the cost per sheet was too high. It was perceived as unnecessary. Plus colour printing was a status symbol, a perq of the important and powerful who had access too it.

But I think going forward when businesses go to replace their existing workhorse office printers they will find that colour is no longer an exotic expensive option just for the executive level. It will just be standard and the cost per page will be the pretty much same as the legacy dinosaur black and white printers. The employees will be very happy with it. Colour printing at work is great.

The zen of software maintenance

We're kind of in a middle phase of our current software project. In the last few weeks we've been focused on fixing as many defects as we can and getting it as stable as possible. Thus new feature work has been neglected a bit.

So pretty much each day was come to work and knock off as many trouble tickets as we could. Now some might find this distressing, focusing on fixing things over new design. But I find I kind of liked it. There's something good about hardening a system, making it better and more stable and enjoyable to work with.

In fact sometimes I could convince myself that it wouldn't be bad to do software maintenance all the time. There's some nice things about maintenance. First of all the objectives are generally clear. The defect is known and reproducible. Fix it. That's nice. Plus you know when you're done. If it goes from not working properly to working properly then you're on the right track. There's a certain satisfaction in going from non-working to working which I find pleasant.

With maintenance it's generally easier. No one is looking for grand sweeping architectural visions or elegant designs. It's just modify the design that was done, the decisions that were made, so that the execution is corrected. Rewrite is costly and generally frowned upon [as it generally should be]. So it's less taxing in some ways.

It's a bit strange for me because in the past I was always focused on being involved with new applications, new code, new systems, new technologies and tools, big new fresh things. But now I'm seeing enjoyment in caretaking the big things other people may have built in the past.

I guess I'm getting older and probably mellowing out some. I'd say based on if my health can hold up and my finances I have 10-30 productive years left. Maybe I'm at least thinking about transitioning to new types of tasks for the upcoming phases in my career.

Now that I've picked up some JSP in the last few months, it is possible that with my background in Ada, Oracle Forms/Reports, and more recently Java that there might be enough legacy code around that I could work with these technologies the rest of my career and not have to learn any big new sweeping technology or paradigm. Especially with Java which hasn't peaked yet and major new blocks of tomorrow's legacy code are still being created today.

But why just think of it in terms of code to write? There may be other roles available that I'm a good match for that are a good transition from where I've come from the last decade+. It's at least worth thinking about.

Translating JSP pages

I've been doing some JSP work the last few months. We use struts. It's not too bad I've found.

One thing struts does pretty well is supporting translation to different languages through the use of keys [aka tokens] into a properties file. This generally works well for the programmer and we generally don't have to worry a whole lot about translation of the user interface screens to different languages.

A challenge can occur when developing a new screen or adding a section to an existing screen. The developer wants to focus on getting the JSP, JavaScript and HTML right. He will typically just hard code the labels right on the JSP and leave it to later when things are working to cycle back and convert the hard coded labels in the GUI to proper keys which have been added or already exist in the .properties file.

The problem can be that under tight deadlines the developer can forget to do this or miss a label or two, especially when there is conditional processing and everything doesn't necessarily appear every time. This can be a big problem because if the test team doesn't specifically test for this then the application can be in the field before the problem is detected. That could cause an expensive patch into the field.

One thing the developer can to do deal with this is to not use the true labels during the screen development when hard coding them. What I use is the prefix "zz". So Name, Address, Number becomes zzName, zzAddress, zzNumber in the hard coded development stage GUI. That way it's obvious looking at the screen I'm not using the tokenized labels and it's a reminder to fix it before shipping. For the programmer you can be sure you have everything by doing a search in Eclipse on "zz" in your code base and it will be obvious if you've missed anything.

For the test team, this can be a somewhat difficult problem to detect. One test case the test team can do is open up the tokens .properties file and prepend "zz" to every single label - this is pretty fast to do using a macro or script. Then restart the app and go through all the screens, including the dropdown lists. If you see anything appear on the new GUI without the zz prefix you know it's a raw, untokenized GUI element, a defect. This is important to test especially in screens where some elements may only occur under certain conditions, or when the screen content can be generated dynamically. Also error messages are a common source of untokenized GUI labels.

technical debt

Technical debt is an interesting term we seem to hear a bit more lately.

I think anyone with experience in software development knows instinctively at least what it is. It's good that people are finally attaching a label to it. It's an important start.

Sometimes a team will seem to make incredible progress on early releases of some product, then may seem to slow down later. There can be a number of reasons for this slow down. One of them is productizing. Another is that with more users people will find more bugs and the team has to backtrack to address them, impeding progress on new features in the process.

But I think what often slows a team down later on is technical debt. In the early releases the team may have used unsound practices such as poor to no source documentation, poor to no unit testing, copy and paste code, heavily intertwined modules, death march project schedules. These shortcuts can yield seemingly rapid progress on a small team with a small code base over a small period of time.

However that progress comes at a price. Like an irresponsible man who lives beyond his means and uses credit cards to fund a flashy lifestyle. He seems prosperous to an outside observer but actually he's heading for a crash and what he has been doing is unsustainable. Technical debt is very similar to that type of financial debt. Much of the early progress is illusory, financed through technical debt. The result is an unmaintainable code structure that will require costly and time consuming maintenance and rewrites.

There are some hazards around technical debt, especially when a new team is asked to take over code originally developed by a different team. If the original team is too willing to part with the original code base then that may mean the code has a lot of technical debt which is coming due and the original team wants to put it on someone else to deal with it. Also with technical debt, if the later team seems to make less progress than the original team, that may be because the new team is being badly slowed by the burden of servicing the technical debt the original team ran up.


One good thing about technical debt now we have defined this "problem with no name" and put a name to it. From there it would be good if there was a way to take the next step and devise ways to measure the technical debt in a code base and in an automated way assign some debt level to the code and estimate the costs of servicing it. I think for some graduate students there may be some interesting and valuable original research that can be done in this area.