Axl Mattheus is a qualified biochemist. He is also the country's leading expert on integration and performance in the Java space. It was during his varsity days that he learnt programming by doing part-time work writing device drivers, in C mostly. Some of the laboratory equipment that the faculty wanted to work with a computer system didn't have drivers, so he taught himself how to write those drivers.
At some point Axl realised that he wanted to do programming and the rest reads like a geeky fairy tale. He went on to do some development work on embedded systems and ended up working for Sun Microsystems as a Solaris kernel developer.When Sun embarked on developing an application server, Axl was picked for that team, and so, he laid some of the foundation of what we know today as Glassfish, or the Sun Application Server. As you can imagine, such work is pretty close to the hardware, and requires a very fundamental understanding of, not only software engineering, but also of the Java Virtual Machine and other deep technical things. Axl now works for Bytes Technology Group, running a crack team of integration and performance engineering specialists. It was at one of his consulting engagements at one of my clients that I got to know him. Axl is also a Toastmaster and a natural teacher.
Things I have heard Axl say while he was consulting on our project include:
"An application server is very similar to an operating system: A dispatcher with thread confinement and memory management"
"In the early days of Java application servers, Tomcat had Jakarta and Catalina, one to take something off the wire, and
one to do something with that."
"When it comes to performance, disk IO is always the anchor you are dragging along. Make use of caching."
"Synchronous communication is vulnerable to performance issues. Imagine running into a wall with an iron bar, something
is going to break. Using queues, does not have the same issue when using a web front-end . Imagine running into a wall
with a chain - no impact except maybe yourself."
It all started when I told Axl that another client of mine is embarking on Agile development. I asked Axl his opinion on Agile. The answer and subsequent conversation was not what I had expected, and was such a revelation to me that I felt it needed to be written down.
Shifting in his chair and adjusting to a more comfortable position, Axl responded with the following opening statement: "Agile, Waterfall, they all have their merits. One is not more mature or even better than the other in all contexts. Yes, Agile may have its benefits and there certainly is a lot of adoption at the moment, but there is a definite place for each. Software engineering will not be a true engineering discipline until we apply the underlying mathematical principles." My response was: "Huh ?" He explained:
In ancient times, King Hammurabi was the first man to formalise liability laws around building. He pioneered
building regulations. Laws like: if a wall you built falls onto your client's animal and kills it, you should
compensate that client in kind, if the wall collapses and kills someone, you will pay with your life, and so
on. Needless to say, the tradesmen in building became very careful about how they built walls.
Building, we call it civil engineering nowadays works differently as it matured. A civil engineer applies the
underlying mathematical principles, which have now made their way into the engineering field as standards. By
using standards, the outcome, or planned workload and efficiency is very predictable. When a civil engineer
designs a bridge, he doesn't first send his child across it to see if it will hold. Then, if it does, sends
his son with a bicycle, then an adult, then an adult carrying something heavy. Yet, that's how we test software.
Look at software contracts nowadays. I was developing software for a heart-lung machine. There, you have to be
very careful about how you develop such systems. There are coding standards for things like medical devices,
aircraft and nuclear reactors (which I did develop software for, by the way).
In the 1800's someone discovered how to project light onto a tube with a cathode ray by applying mathematical principles. Then some industrialists found out how to take that concept into production. The television became a commercial success. It was time for mass-production. Today, all the components are ready-made, and unskilled labour assembles it in a factory. That is how software will be built in the future. And when you have that, Agile and waterfall doesn't matter so much.