Archive for January, 2006

Printers going Java

January 4, 2006

Embedding Java doesn’t always equate mobiles. Nor does it necessarily mean stuffing it into a rover on Mars. Introducing new possibilities is sometimes just a question of putting it on a small card hooked up to your printer.

Axis, a well-known creator of print servers, network cameras etc has done just this. They took one of their print servers and added Java for a big time printer manufacturer in Japan. How did they do it? And what did they learn? I teamed up with three of the people – Jens Johansson, Kristofer Johansson and Stefan Andersson – behind this Java enabled print server to get more of the gory details.

The Start

The project started around four years ago with a prototype after some seven months. The release onto the market was roughly one and half years ago. The first step, however, was to assess the feasibility of it. Could they perform to their customer’s demands? What type of handling of Java classes should they use just in time (JIT) or ahead of time (AOT) compiling? Even the choice of hardware wasn’t given from the start. Should they use third party chip dedicated to running Java or do it themselves? The former would have meant a bus and shuffling data in between the main chip and the Java chip.
Not interesting. Ten man-years later, here’s what they
ended up with.

A schematic view of the print server and its different parts. The functionality is extended by uploading Java classes as a normal jar file.

The Box

First off they had to decide which road to travel – base it on a hardor software? Roll their own or go third part?
Buying an ASIC block doing the Java and integrating it on their chip architecture would have been very expensive and wouldn’t have resulted in a cost effective system. Buying a third-party chip? That would have meant hooking it up on the system bus and making the whole system rather complex. In the end they settled on a software solution and doing it themselves.
Basically they took the Axis ETRAX 100LX chip, added more memory and used software to implement the Java support. The ETRAX 100LX systemon-chip is a 32 bit, 100 MHz RISC CPU. The design then uses the Java 2 Platform, Micro Edition (J2ME) with the CDC and Foundation profiles. This resembles the abilities of a PDA or a set top box on your TV.

The Java foundation classes reside in a separate memory and are loaded by the print server before any uploaded jar files from the file system on the board are run. The memory is divided into a 16 MB file system and 16 MB for all the executable code including the Java Foundation classes. Add to this a 64 MB RAM that houses the system, of which approximately 13 MB is used for Java. This is considerably more than the standard print server that typically has 4 MB of memory.

The operating system is Axis’ own proprietary RTOS for embedded systems. The unit consumes a sparing 0.3 W.Add to this a USB port and you get a pretty good idea of this competent little circuit board.
You change the function of the print server by uploading an ordinary Java jarfile. These compiled classes are then run on the print server and have access to the various ports and, of course, to its printer.
There is even a remote call possibility (RMI) to query the server for its status et al.

The result

Even though there were apprehensions at the start of the project about the performance, the result speaks for itself. CaffeineMark 3.0 is a Java benchmark. It is used to measure the speed of a Java Virtual Machine (JVM) running on a particular hardware platform. The test is calibrated to return a score of 100 running on a Pentium 133 MHz using Windows 95 and Sun’s JDK 1.1 interpreter. Even though this feels like an old PC, it does give you a good reference point for embedded solutions.
Axis’ print server landed on an impressive 60. This result is even more to write home about since the entire floating-point math is done in software.

The Lessons Learned

As with most projects, there were problems to overcome. In this case the floating-point library proved to contain bugs. The TCP stacks used at Axis were different compared to the Sun version. There were compiler issues going from Java to C. As coup de grace they needed the Java logo and that meant going through a grueling TCK test (Technology Compatibility Kit). This is a suite of tests, tools, etc that provide a way of testing an implementation for compliance with a Java.
”This has been among the most complex printer projects we’ve done ”, says Jens Johansson with a weary smile. However, the Java portion worked without any major problems as soon as the foundation classes were in order. ”For one and half year we haven’t had any Java related bugs”, explained the tech lead Kristofer Johansson.
They chose AOT compiling to implement the foundation classes, but this meant a large code base and it took time to implement. Hindsight is one of the best visual aids: might it have been better to use JIT instead?


So techno stuff is all just fine, but what can we do with this Java enabled print server? Ever forgot about an important printout that shouldn’t lie around? Well, why not a simply hook up a card reader? Once you arrive at the printer you swipe your card and, presto, your pulp stack pops out. Authentication and authorization could be done against an LDAP server.
Still too simple. Why not implement a distributed load-balancing scheme for printers – next available printer pulls a job from a print queue somewhere. Need more power? Just hook up another printer to the network. Could I combine the print server with a web camera and motion detection? Add something to sample the temperature and we get surveillance, fire detection and printing to go.

Puleeze Axis, can I get a couple of print servers to try out?

Originally published in JayView.

Scrum down!

January 4, 2006

Scrum is not another rugby term*; it is both a rugby term and the name of one of the hottest project management processes to come off the assembly lines. Yes, it actually draws its heritage from Toyota and lean production! Most of it is just common sense though.

A scrum is when the teams pack in a special formation in rugby, head to head, in order to gain possession of the ball.
Here is the opening explanation from Wikipedia, assuming someone didn’t change it after printing.

“Scrum is an agile method for project management, first implemented by a team led by Jeff Sutherland at Easel Corporation in 1993. It has been called a ”hyper-productivity tool”, and has been documented to dramatically improve productivity in teams previously paralyzed by heavier methodologies.”

That sounds too good to be true! What is this?

* A scrum is when the teams pack in a special formation in rugby, heads to heads, in order to gain possession of the ball.

The short story

Scrum is an agile, iterative process where small self-organizing teams focus on producing a working demo of the system at the end of each sprint, iteration. One such sprint is typically four weeks.
The product owner handles the product backlog. This is a list of prioritised features or activities. At the start of a sprint, the team and product owner collaboratively select a goal for the coming sprint. They then select the product backlog items that best support that goal. These backlog items are then decomposed into the necessary tasks. This is known as the sprint backlog. While the team may add or remove items on the sprint backlog during the sprint, the sprint goal remains unchanged.
Through 15-minute daily meetings the team shares status information and the Scrum master removes any obstacles (impediments). The Scrum master controls the process, but the team is totally in control of the implementation.
An executable is presented at the end of the sprint. After this demo, a new sprint starts and a sprint backlog is created.

An overview of the Scrum process.

What is the problem anyway?

Several methodologies assume that building a system is something you can define or specify up front. The struggle to attain this level of confidence is often a difficult up hill marathon or just plain futile. Even small projects need to adapt during their implementation. Scrum, on the other hand, recognizes
that IT is so complex that the only way to control it is through an empirical process. Watch the process. Constantly monitor it in order to get the desired output. The complexity, or our inability to fully understand the problem, has become a dogma.

Who’s who?

The roles in Scrum are actually quite few – Product Owner, Scrum Master and the Team Members.

The Product Owner

First we have the product owner, and this perhaps is the easiest role to understand. This person handles the product backlog and is responsible for setting the priorities for the product.

The Scrum Master

The Scrum master is not far from being a project leader if it wasn’t for the many things he/she does not do. The Scrum master protects the group during the sprint, removes impediments that hinder development and guards the process itself. He or she does not hand out assignments, dictate a solution or even make decisions for the team.

The Team Members

This cross-functional team is made up of around seven people with different background – programmers, testers, etc. They self-organize and structure their work. This means they alone decide on how to form a working group that can implement a solution to reach the sprint goal. This is important and slightly terrifying. Scrum seeks to unleash the group’s potential to strive for a goal as effectively as possible. The group therefore not only has the normal burden of obligations, but more importantly the right to decide how it should be done. This means the group could decide to use its cousin XP (extreme programming) as a base for their development model or perhaps RUP.

Why so few people? In order to get a closely-knit development with fewer overheads, as is typical in agile projects, the group cannot be too big. Even the physical distance will affect the outcome. Going further than a ”coffee cup walk” could be a problem.

Why so many people? I’ve heard people say that a group should not extend beyond 3-4 people in order to stay tight and focused. Scrum, on the other hand, seeks to reach hyper productivity where the group is drastically more effective at cranking out solutions. Call it synergies. Call it direct coupling of brains. Whatever the name, people can be a lot more effective when interacting without obstacles. You get too little of this if the group is too small.

The Process

Scrum is built up around the sprint, or the iteration. Though before we can start, we need a Product Backlog. This list contains everything that needs to be done on the project – stories, activities and so on. The product owner prioritizes every item.

The Sprint Planning Meeting

The sprint planning meeting sets off the iteration and produces a sprint goal and a Sprint Backlog. The goal and this list is the sole target for the team during the sprint. Tasks may by adjusted or split during its course, but no new no product backlog items can be added to the sprint. No boss sidetracking the Scrum master, no desperate plea from the salespeople can alter the backlog. This produces a box of calm that lets the group do real work instead of endless switching between tasks and trying to hit a target that is constantly moving.
Is there no way to change the list? Well, there’s the simple case when tasks are completed faster than planned. The group can then decide to take on more tasks. In some cases, the product owner can OK changes to tasks in order to meet the deadline.
And of course there is the ultimate change the sprint is cancelled; but that is a rather drastic measure.

The Daily Scrum Meeting

How do the team steer the work effort? How does the Scrum master know that all’s well? The answer is the daily Scrum meeting. This meeting lasts roughly 15 minutes and each team member is responsible for answering three questions:

  • What have you done since the last Scrum meeting?
  • What is preventing you from doing your work?
  • What will you do until the next daily Scrum meeting?

The Scrum master will pay close attention to what is said and how it is delivered. Are the team members doing what they should be doing? Is work progressing as it should be? Is the group functional or is something hindering it from performing?


To track progress the team uses a Sprint Burn Down Chart. In this graph we can find the number of hours left to do and the number of days available. Hitting deadline is then a question of making sure the line reaches the x-axis by the last day.
In the example graph above we can see that the group’s remaining hours actually increased around day five. The level of complexity was fully understood at this point in time. On day six a meeting with the product owner resulted in a change in ambition and made it possible to reach the sprint goal, albeit with a reduced ambition.

The Sprint Burn Down Chart. Each Scrum team tends to have a ”signature” on how the remaining hours de- crease. Note the bump around day five.

The Sprint Review Meeting

The sprint’s final meeting is the review where the most important piece of artifact is shown to the product owner and others who might be interested – the executable. This piece of code should be something that is actually running. It might be small, it might just do one of the many things it will do in the end, but it is real. This means that there are no mockups, no PowerPoint slides and no dummies – just real stuff.
This concludes the sprint where we’ve done all the designing, coding and testing that is needed to get the executable part of our system to do a demo.
One more thing; the artifacts we need are marked in bold above, not a lot and very focused.

Scale? Control?

Having come this far you might be saying:
”This all sounds all well and good for the programmers, but it can’t scale.”
Actually, it can. By setting up a Scrum of Scrums – the Scrum masters from different projects form a Scrum of their own – you can scale up, as Jeff Sutherland has, to more than 500 people.
I asked Sutherland whether Scrum doesn’t fail sometimes:
”A high estimate would be that 5% fail, but they do so in two weeks.”
There are a lot of projects that take a lot longer to implode than a mere two weeks.
Scrum accommodates the complexity of IT and can increase efficiency drastically. It’s all about common sense and daring to live close to chaos. You let the team free and then check progress. Set free and monitor. Let go in order to gain control – a true paradox.

In conclusion

The process, the artifacts and hopefully even this article are easy to understand. However, Scrum is more, it is also a mindset. Without a deeper understanding of the process, the desired effects might not just appear. It’s a bit like mimicking Rembrandt, armed only with the angle and speed
of the master’s stroke. This is the only project management method that I’ve found I can relate to. So my final question has to
be… You wanna Scrum?

Originally published in JayView.