System designers and software engineers may differ significantly in how they define the success of a system. No pair of software projects illustrates this better than the MULTICS and UNIX operating systems. MULTICS was initially developed at MIT from 1965 to 1970 by a team from MIT, GE, and Bell Labs. It had many complex features to help engineers build application software. The designers hoped it would be the most useful operating system ever.

In 1969, Bell Labs left the team. Shortly after that, Dennis Ritchie and Brian Kernighan, who had worked on MULTICS, began playing around with their own more straightforward operating system. Their approach was very different. They focused on writing small, simple utilities that could easily interact. This operating system was called UNIX.

Tom Van Vleck, a member of the original MULTICS team, relates a story that illustrates the significant differences between the two systems. "I remarked to Dennis [once] that easily half the code I was writing in MULTICS was error recovery code. He said, 'We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"

A formal definition of software quality is the extent to which the software meets the requirements. These two groups of brilliant and motivated people had two very different views of success. However, if you base success solely on the system's needs, both systems were equally successful. Yet, UNIX (precursor to Linux) has been more widely used and reimplemented than MULTICS. So, there must be more to building a successful system than just meeting the system's requirements.

Defining success as simply meeting requirements paints an incomplete picture. Completing the system's requirements does not make the system a success if the requirements do not address ease of use, performance, or aesthetics. Agile project management practices have pushed this hole in requirements understanding to the forefront by integrating user stories with test-driven development. However, it is challenging to create a reproducible test for the aesthetics or ease of using a system. So, developers happily push this problem back to the product designers and let them work it out. They'd like to think that if the tests fulfill the user story, they have built a 'quality' system. In reality, all they know is that what they implemented was implemented correctly. They don't know whether they have implemented the right thing or not.

Fred Brooks stated in The Mythical Man-Month that the purpose of software is to make a computer easy to use. If this is true, we need to define a software development project's success according to its ease of use. There are many tools to evaluate the ease of using a system, such as the System Usability Scale. One that the UX team at POMIET is interested in measures the flow a user maintains when using the system. We have begun to measure flow in a naive way by answering one of two simple questions. For a system intended to be used for long periods, can a user who is free of external distractions, focus and be productive using the system for 30 minutes or longer? A question for the user of a system intended to be used for a short time may be, "Can you accomplish your goal using the system with little effort or while doing something else?"

The most basic reason for considering focus/flow as a measure of success is the humanistic view that focus is fundamental to productivity. What do we have to do to design systems that promote peace of mind? Studies have shown that qualities such as color, screen layout, and wording promote usability. These qualities do not directly affect the functionality of the system, but users find systems that value these qualities easier to use. The studies also show that usable but tedious software might evoke a similar response to those complex yet delightful systems.

Mihaly Csikszentmihalyi spent years studying what satisfies and fulfills people. He is known for his notion of flow, which he described as "being completely involved in an activity for its own sake. The ego falls away. Time flies." Csikszentmihalyi found that people reach their best performance at a level of optimal excitement, where neither over-stimulation nor monotony is present. This optimal excitement involves an activity that is both challenging and attainable.

The next time you embark on building a new system, be sure to include qualities such as ease of use, aesthetics, and flow in the requirements. Your users will be grateful.