CleanCode logo
sitemap
SEARCH:
NAVIGATION: first page in sectionprevious pageup one levelnext pagefinal page in section

Philosophy

Focusing on making systems work throughout my career, in large corporations and Silicon Valley startups, my emphasis has always been user-centric: usability, maintainability, user interface issues, ease of use, and documentation. I refer to these in a broad sense (not just for the front-end of a system) and encompassing both internal & external customers. But in this frenzied development world, good documentation (for the development team), good design, and good diagnostics, are vital.

So what is good design? A good piece of software is one that is easy for the external customer to use, easy for the internal customer (developers) to understand, difficult to break (either internally or externally), and straightforward to enhance or maintain. One that translates into savings of real dollars. Necessary dimensions are clean code, encapsulated components, well-defined interfaces, self-diagnostic systems, and thorough documentation, inside and out.

I'll just touch on one other aspect of good design. Generally speaking, few companies would begin a project without good specifications. But, in my experience, few companies would continue a project with good specifications. What I mean by that is typified by a new person coming into an existing project. Yes, one could read the original specs, but often they no longer reflect reality -- things have been added, deleted, changed. And what about issues that have evolved in a project from experiential data? Try finding something written down. I am continually amazed -- particularly now that I have moved more towards software contracting and I see more projects in progress -- that engineering is not far removed from our ancestral cave-dwelling days, where ideas were passed on via oral history. We have come full-circle. I believe it is vital that a good piece of software should be able to tell its own story. CleanCode describes diagnostics vs. self-diagnostics, and how they can be used together to allow the software to speak for itself. I describe how they are used here as well as examples from my work at Tektronix and OzEmail.

CleanCode will also talk about design from the user-interface perspective, focusing on web site software, since the reader has the opportunity to visit the web sites discussed. I will even assert that user-interface design should, in general, not be done by the software engineer (a point that could be considered contentious). Software people are notorious for creating geeky interfaces. Even those that think they don't, often do. The user experience requires a specialist. The situation is akin to the realization during the desktop publishing boon in the 90's that a person with a desktop publishing program does not a graphic designer make. Same thing here. Just because there are whiz-bang tools to create a website doesn't make one a website designer. That being said, if this book helps the reader get a bit closer, though, then my goal will be achieved.

Valid XHTML 1.0!Valid CSS!Get CleanCode at SourceForge.net. Fast, secure and Free Open Source software downloads
Copyright © 2001-2013 Michael Sorens • Contact usPrivacy Policy
Usage governed by Mozilla Public License 1.1 and CleanCode Courtesy License
CleanCode -- The Website for Clean DesignRevised 2013.06.30