JLOFT: Accident Vs Excellent
Our two very fine Eiffel engineers have been great mentors. The staff of Eiffel Software have also been excellent mentors and helps. The names are numerous so I won't list them. From them we have and are learning a great deal. What follows is a list of some of those lessons presented as titles:
Accidental is Flash-panned: Excellence is Forged
The Elegance-Excellence Interchange
Design by Accident Vs Design towards Excellence
"No 'I' in Team"
Safety to say the Stupid
Elegance: Don't Forget the Data
I have spent the better part of the last four weeks pouring over, contemplating, considering, laboring, learning, growing, discovering and enlarging upon the concepts that are coalescing into some form of an accounting system. The process has not only involved myself, but several others including both the software team and the business team (accountants).
While the labor has been to form up the data structures upon which the accounting engine will operate, those data structures have been only a part of the overall process. Other products have been the Master Chart of Accounts that define the "buckets" for "A place for everything and everything in its place." Another product has been the Master Transactions that will operate upon the Master Accounts and how they ultimately look in both the Journal and the General Ledger. Behind these has been a great deal of study; relearning, growing, expanding upon and enlarging our understanding of the GAAP Principles that guide the entire process.
All of these processes and labors are leading up to the foundation upon which the new Eiffel-based accounting engine will rest and operate. Thus, it is imperative for the foundation to be as excellent and elegant as possible by this team at this time to facilitate and match the code design that is coming -- even to help shape the code from the work before it.
From these processes and the Eiffel code built so far have come some important lessons previous enumerated above as titles. Not one of them is trivial, because reality is never trivial.
Accidental is Flash-panned: Excellence is Forged
and
Design by Accident Vs Design towards Excellence
Almost anyone can create a quick, off-the-cuff and flash-panned solution. The more experienced someone is, the better that initial cut of a solution or design may be. Nevertheless -- even the "old hands" and "old pro's" still require time, energy and mental labor to move from the initial take to the final product.
Because software is malleable (soft and easily shaped and reshaped), it is not only an excellent candidate for excellent and elegance, but for slop, trivialities, ignorance and "quick solutions" to enduring problems. The choice of which product to produce is in the mind, heart and hands of the engineers building the product.
One of our Eiffel engineers put it to us this way very early on: "I find that software projects reach a place where they feel like they are stalling -- that is -- you reach a place where you step back, look at your code, consider it, tear it down a little and rebuild with new insights of what the wrong course was and what the better course is." This simple and core reality-based principle has become a staple on the JLOFT Eiffel project.
What has become increasingly obvious is how quick solutions are accidental solutions: maybe you get it right, but mostly -- expect to get it wrong. The surest sign of being in this ad-hoc and accidental mode is when the programmers start applying "band-aid" code simply to "make it work." Thus, hearing a programmer say something like, "Well, it works" or "I did that to make it work" is a large clue that the project has gone off the rails of good design and into the morass of the flash-panned.
The Elegance-Excellence Interchange
and
Elegance: Don't Forget the Data
Code that is elegance is also excellent. Excellence is measured not simply by Correctness and the other Quality Factors. Excellent and elegant design makes use of the tools to craft code into mechanisms that are usually simple at their core, non-band-aided and have a high re-usability quotient.
Another point to make is this: Elegance and excellence are not found just in code, but in data structures as well. Working on this accounting system has certainly taught me this lesson.
"No 'I' in Team"
and
Safety to say the Stupid
Very few of us on this wide-team (Jinny + Eiffel Software) are Masters. Most of us seem in the middle or the bottom of the learning pool. While I am higher than I was, I won't even count myself to be in the middle (speaking only for myself). Nevertheless, there are some important lessons to be learned from working on a team and not just as an individual.
Brian Leahy (and I am sure Neal Lester would agree) made a reality-based observation: He said, "I have noted over the last month how the Jinny people have made very significant contributions to the effort." He was noting the contributions specifically to design ideas -- things we were learning to see and contribute that otherwise would have gone unnoticed for a longer period of time and perhaps forever.
There truly is no 'I' in Team. While our design skills and technical experience and prowess may not be much, there seems an expanding room to contribute in significant and meaningful ways. This would not happen without a team.
Another factor clearly coming into view is how the people on this team have built an environment where it is safe to say the stupid. Not every suggestion is a contribution. Some suggestions, observations and verbalized thoughts are either not right, irrelevant and -- ahem -- well, stupid. I have made them. Some of my counterparts have as well. Sometimes we've noticed and other times not. Regardless, the team has responded by simply letting it pass by (if noticed) or has appropriately and even light-heartedly corrected. It is a good policy provide each other such allowances and trust we will not remain where we are, but are a work-in-process with the personal goals of self-improvement.
Oh yes -- one final note: Someday soon, I will actually write a more "technical" blog entry. Still, it seems important to point towards some of these high-level matters and human factors as software engineering is (after all) a deeply human endeavor, requiring courage, cooperation, good technical knowledge, tools and everything else people can muster to meet the challenges at hand.