JLOFT: Training Wheels

At the present time, each new day of working with Eiffel shows me both how far I have come and how much further remains to go. A faithful saying is: "Whatever you focus on expands." Working with Eiffel is no exception to this rule.

We are learning and have learned a great deal in the last two and half months of working with our two very fine engineers. I am constantly and inwardly reminded of where we started: knowing almost nothing (as a team). Relative to this position, we've come a long way.

We can talk with some relative intelligence about inheritance and genericity, events and agents, callbacks and data types, et al. However, the speed at which we can process this information and the depth of our understanding is still shallow. I was relating to a friend how I see us still in the wading pool, while we watch the big kids in the deep end and flying off the diving boards at the other end.

A question with growing intrigue is: How do we get to that end of the pool?

I have been rolling this question about in my mind and a strategy is forming. It is certainly a matter to discuss with the team, but it seemed appropriate to let any reader of this treatise be included -- if for no other reason than to get a good laugh! :-)

We presently are working with a staff of six people: four W-2 employees and two contract engineers out of Goleta, California. From the start, we have been working in two teams of three each, consisting of one contractor, one senior Jinny person and one junior. So far, this has been working well.

The teams have been following a pattern of pair programming + one, where there is one driver, one senior observer (the contractor) and one alternate observer. The two Jinny team members have been switch-hitting between alternate observer and driver, while the ISE contractor has been always in the senior observer seat, with very minor stints in the drivers seat as the need has arisen.

From time to time, we have even swapped out the ISE contractors between the two pairs of Jinny engineers, just to get a different flavor and keep the teams fresh. I certainly don't want us to get into any ruts and get too comfortable and only get one point of view. Both of our ISE contractors have their own flavor and approaches; certainly their own personalities and thinking when it comes to how they design, code, test and so on. So, it has seemed very appropriate to take full advantage of this reality and keep the pairing and combining of people and talents in motion at all times.

Now, we come to a new horizon that we have not reached, but it is now within sight of where we are presently traveling. This dot on the edge of our project vision has to do with a time when the training wheels will come off.

The ISE contract engineers are very expensive. This is a simple fact. They are VERY good and we could not have come to where we are without them. Nevertheless, the opening rounds of this game are costly and -- ultimately -- we, as a corporate team, need to find our way to self-reliance and self-sustainability. We need to take the appropriate steps towards a day when we take full command and control of the engineering project for ourselves on a daily and regular basis and the help from ISE takes a step towards a more background rather than foreground role.

The achievement of this goal -- that is -- the graduation of the Jinny team will come like any other: The team must start (at some near point) to split off and work on its own, but within the watchful eye of "Mom and Dad"/"Mentor"/"Teacher". Moreover, the team must be PROVEN. That means, the kid-gloves come off, the training wheels are briefly removed and a small representation of the Jinny team is shoved to the edge of the nest to stretch its wings and learn to fly.

The vision in my own mind is that we cease to operate in teams of three, but fully take on three teams of two paired engineers -- that is -- one of the two-man, paired teams will be two Jinny engineers working without the direct supervision or help of an ISE engineer. Yet, the ISE folks won't be far away to offer help and feedback. Moreover, there is this matter of proving.

Another layer of the vision is how the Jinny-only team will operate with a heavy layer of peer review from the ISE engineering staff. It seems right to have that code review of design, style and implementation happen on a daily basis at first. Moreover, it seems appropriate that such a review ought to include the possibility of saying to the Jinny-only team, "No, _______ is not right. Back up. Re-write it. Start over. Do it again. This time, do it this way or that."

My sense of the matter is that this will be the forerunner to a Jinny team that will be certifiably ready to take the reigns when that time comes. I already sense that such a process will be hard. I also sense how we may face what may seem insurmountable barriers or blocks, but ... isn't that just the way it is? I just do not see any other way to ensure myself and my Jinny colleagues can have any justifiable self-assurance of our own capacity to take this project to a successful completion.

The simple reality of the matter is this -- WE MUST!

That said -- we're not there yet. Still, it's coming. The dot is out there on the horizon. I can already see it. I sense the thing. It's exciting and it scares the living daylights out of me as well. It's like watching the needle on the end of a syringe filled with the medicine I need and I know it will heal, but it's simply going to hurt to get there.

Don't let anyone fool you. Eiffel is not simple. Yes, there are only a few handfuls of keywords. Yet, keyword count is a false measure of complexity. The real complexity is not in the language, nor in the method. The real complexity is in the art and science of software engineering; the logic, math and reasoning behind it. The Eiffel method and language help to organize and put handles on that complexity in ways no other language system I am aware of does. Nevertheless, if there is anything coming very clear to me of this experience, it is my own immaturity as a software engineer.

It's time to grow up! That is the real professional gift that Eiffel, the method and language are bringing. We're about to find out if we measure up. I think we will.

P.S.

I am unaware of any software system (language and method) that is NOT complex. I am also unaware of any software system that ultimately does not touch the underlying science, math and logic inherent in a computing system. Yet, here is a stark difference I am experiencing between Eiffel and other software systems I have used. The complexities of other software systems I have experienced are more about the notations and logical structures of the system than they are about the science, math and logic beneath them all.

Eiffel is the reverse. It is less about its own language complexities and more about what lays underneath. It's more about the science, math and logic than it is about commands and code structures. Eiffel doesn't bolt on some new "widget" to solve a problem created by the language structure itself. When and if needs arise, Eiffel uses the simple and elegant tools it already has: Classes, keywords and a solid method.

Eiffel simply focuses on the meat of the problem and not on adding more complex fluff at the edges of the problem. This "closeness to reality" and "thin layer" of tools that allows me (as an engineer) to reach out, touch, manipulate and ultimately use and tame reality through my software text in elegant and even beautiful ways makes working with the language and method of Eiffel a very satisfying and rewarding experience. It also works out to software that truly gets me to where I know I ought to be: Quality Software Solutions to Real World Problems.