Lifelong Learning

Outrageously Great Software - Starting Thoughts

To be able to deliver great software, we need to be mindful of software quality.

One of the best expositions on software quality I have found is Chapter 1 of Bertrand Meyer's Object-Oriented Software Construction. Nineteen pages of the best advice on what constitutes quality software. Rest of the book (1200+ pages) is very concrete, detailed, and specific design and construction advice on how to actually achieve quality software. The short version of the advice is to focus on correctness. How do you ensure correctness? Design By Contract - Chapter 11.

What are the quality attributes for software? According to Meyer, they are the following:

• Correctness. The ability of software products to perform their exact tasks, as defined by their specifications.
• Robustness. The ability of software systems to react appropriately to abnormal conditions.
• Extendibility. The ease of adapting software products to changes of specification.
• Reusability. The ability of software elements to serve for the construction of many different applications.
• Compatibility. The ease of combining software elements with others.
• Efficiency. The ability of a software system to place as few demands as possible on hardware resources.
• Portability. The ease of transferring software products to various hardware and software environments.
• Ease of Use. The ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation, and monitoring.
• Functionality. The extent of possibilities provided by a system. How much functionality is enough? Do you sacrifice reliability, extendibility, etc. for more functionality?
• Timeliness. The ability of a software system to be released when or before its users want it.

Tradeoffs are necessary, as these factors may conflict with one another. Economy often fights with functionality. Efficiency may require perfect adaptation to a particular environment, which is the opposite of portability. Reusability requires solving problems more general than the one initially given. Timeliness may require using rapid techniques whose results may conflict with extendibility. A true software engineering approach implies an effort to state criteria clearly and to make the choices consciously.

Necessary as tradeoffs between quality factors may be, one factor stands out from the rest: correctness. There is never any justification for compromising correctness for the sake of other concerns such as efficiency. If the software does not perform its function, other attributes are useless. I recall a conversation with a client who insisted that we make the software much faster. I explained to the customer, that I can make it extremely fast, if it did not have to do all these things that he wanted it to do. That is the definition of a useless quality attribute! Very fast, but doesn't do much.

So I maintain that outrageously great software is software that does what it is supposed to do, in other words, honors its contract with its potential users. A user of a piece of software, most of the time, is another piece of software. Only the UI modules of a software system have humans as the end user.

So to deliver great software, it would pay to know how to make a software module honor its contracts with other software modules (tests are those software modules that represent the user). This leads to the realization that great software boils down to DBC - Design by Contract!

Other definitions, of course, abound. Great software is great because:

- It generates great revenue for the company.
- It is a great market success
- It is great performing. Lightning fast.
- It has a great user interface.
- It is bug free. Never breaks down.

You can deliver great software by other means, like test-driven development, and by being relentlessly test-driven. Having explicit contracts checkable at runtime, is complementary, and will get you there faster.

A System Development Process Using ORM

Outline of an agile, and very rapid, system development process utilizing ORM (Object Relational Mapping). Hibernate is used as an example to make the discussion more concrete, but any ORM will do.

1. If you have an existing data model extract your domain object model from it. Refactor object model to fit your requirements.

If you don't have a data model, come up with a domain object model from your requirements. Create a database schema from the domain object model. Don't go to step 2 until you have a domain model synchronized with the data model (synchronized does not mean identical!). If you are allowed to refactor the data model, do it. If not, live with it (and curse the DBAs!), but refactor the object model you must. If you have a highly denormalized data model, normalize it using Hibernate components and class-hierarchy mappings. Decent thought work needs to go into this. Can't be blindly automated.

Don't follow mad processes, like RUP, that tangle you up in use-case hell, and an object model that "falls out" of the use-case model through a bunch of VOPCs (View of Participating Classes). That's total hooey. Nail down the domain object model. Look into domain-driven design (Eric Evans).

2. Do steps 2.a and 2.b in parallel.

• 2.a Create a skeletal (canonical) implementation of the data access layer's API using HQL and DAO objects (I prefer DataManager Objects).
• 2.b Define and implement unit and acceptance tests for the data access layer's API. This should be much simpler than the tests for the domain layer, since you are mostly implementing CRUD operations. But make sure at this stage to test business rules and data integrity rules (mainly having to do with correct object creation/deletion and relationship maintenance). You don't need to worry about business logic or business process at this stage. This separation of concerns can save you great deal of work later and is key to robustness of the domain layer which will rest on top of the data access layer.

3. Do steps 3.a and 3b in parallel

• 3.a Implement the domain layer. You can proceed one-story at a time, or one subject-area (a set of collaborating objects) at a time. I prefer the latter, but your project tasking may differ (if planning by story).
• 3.b Define and implement unit and acceptance tests for domain layer. Now is the time to think about business process and business logic. Use an acceptance testing framework like Fit (Framework for Integrated Tests - Ward Cunningham). You are resting on a solid foundation of a tested data access layer.

Note that in both layers you can follow test-first, or test-last approaches. I prefer test-first. It makes tests drive the development - but that is not a requirement - merely a preference and a sequencing decision. First, or last, make sure you have sufficient unit and acceptance tests implemented.

4. Implement continuous integration making sure your unit test suite and acceptance test suites run with each integration.

5. Don't let the GUI distract you. Implement as little of the GUI as you can get away with - preferrably none. Once the domain model API is functional, stable, and robust you can pay more attention to the UI. If the UI is necessary for demonstration to stakeholders, implement the UI in slices on top of fully tested domain layer. I like to implement a complete text ui, or a domain-specific language,  that exercises the domain APIs.The GUI is left to the usability and presentation layer specialists, who will use the text UI to learn and exercise the API before they hook into it. They can have all the creative freedom they need to come up with the most user friendly and the best user experience they can come up with, comfortably knowing what the domain layer is capable of giving them.

Note: Many customers will not allow the implementation of a text UI, or a domain-specific language (as it seems unnecessary, since the text ui, or the language interpter, is not made available to the end user), but for those customers who allowed me to use it, specacular results in terms of a very rapid schedule, and very performant code, were achieved. In the schedule, I put that layer under "acceptance test framework", and that was acceptable to customer management, who were glad to pay for the high quality and the rapid schedule.

Constructive Confrontation

At Intel, the largest semiconductor maker in the world, all full-time employees are given training in "constructive confrontation", a hallmark of the company culture. Intel preaches that the only thing worse than too much confrontation is no confrontation at all. So the company teaches employees how to approach people and problems positively, to use evidence and logic, and to attack problems and not people.

Intel's approach is backed by a series of experiments and field studies done at the Kellog Business School, Wharton Business School, and Stanford showing that destructive conflict is typically "emotional", "interpersonal". Groups that fight in these ways are less effective at both creative and routine tasks, and their people are constantly upset and demoralized. In contrast, these researches find that conflict is constructive when people argue over ideas rather than personality or relationship issues, which they call "task", or "intellectual" conflict.

The above two paragraphs are both verbatim from a recent book by Bob Sutton, The No Asshole Rule.

Also checkout this site.