|
P |
|
|
|
Philosophy (Perfect Software Engineering)
Executive Summary: Simplicity complements Quality. We can accomplish more when we try to do less. We must be strongly motivated to focus on what we do rather than how it looks.
KISS - Keep It Simple, [Sherlock]:
Simplicity is the key to everything. With a simple enough idea and design, “anyone” could manage to get a working implementation. With an over-complicated idea, and no design, no one could get it right. Keep it simple, and you’ll get it done. Make it fancy for the sake of glitz, and you will find the quality of the idea cannot compensate for the fact that it is vaporware (software which doesn’t exist, and often is long-anticipated. The classic example was always Duke Nukem Forever, which did however manage to release after fifteen years).Quality:
Read Zen and the Art of Motorcyle Maintenance for the best description of Quality I have ever found. I am convinced by it that there can be no single, perfect description of Quality, but that it is nonetheless real and can be recognized.But to me, in terms of software, it relates to good (thorough, accurate) design & documentation first. Without this, even the best software will be unable to change, and quite possibly, be unable to even be used.
Part of the quality of the design lies in multiple perspectives: some of the more obvious are functionality and architecture. But it should also cover security and accessibility, important and critical areas too easily overlooked or simply claimed without any further detail or justification, like “Software should be secure.” Of course it should be. But the design needs to acknowledge the attack models considered, how they will be defended, what sorts of attacks will not be prevented (for instance, if a user’s login and password are known by an attacker, very few systems have any further security. This may be acceptable in many areas, but it should at least be acknowledged as a limitation of the system, so that designs to counter it are known to be out-of-scope. And if it is going to be addressed, then that is absolutely something which will need to be planned for from the very start. And of course, the “login-and-password” system itself is severely limited and inappropriate for high-security systems, but that’s a whole other topic.).
Quality in the code itself lies again in simplicity (without loss of expressiveness), its own internal documentation, and, of course, actually doing what the design says it will. Very little code manages to get even one of these totally right, often due to having been written in a hurry without sufficient planning.
Maximum efficiency through minimum effort:
I shamelessly stole this one from judo, where it is the first principle (of two, the second being: mutual benefit and welfare). This is my counter to being “cheap”. Most of the time, “cheap” is just an excuse for being penny-wise and pound-foolish. I strongly believe that investing properly at the beginning is the only way to avoid serious structural deficiencies later in a project. I find analogies to building a house useful for understanding software engineering principles: would it be wise to “save money” by skipping the design phase of a house and “just building” without a blueprint? No one (I hope) would be so insane. Yet the analogous behavior is common in software. Would it be wise to “save money” by skimping on the foundation? Yet many clients (and even so-called designers) are focusing on the paint color before a blueprint has been started or a foundation laid.Instead, the way to minimize costs is to find ways to reduce effort. Simplicity, as stated above, is an excellent start for this. Quality is necessary because it reflects the “minimum”: doing less there results in more work ultimately. But it goes further than that. In this field there is a concept that the “lazy” programmer is the best type of programmer. This is because “reinventing the wheel” is a common mistake. As soon as you do this, not only is there the cost of initial development, but there is the maintenance necessary on the re-implemented work. Whenever possible, it is valuable to use existing tools and libraries.
Of course, the devil, as always, is in the details. It is simplest to use an existing, free forum if you just want to have a forum, certainly. Yet if you want total control over the design, and wish to do things differently, it may be simplest to start from scratch. This wouldn’t be reimplementing the wheel, but redesigning it. Human discretion is always the bottom line; aphorisms can only be guidelines.
We’ve never done a job we wouldn’t have done for free (in a world where that were practical):
We will never take a job just for the money. It always has to be a project we want to do. This principle is about making sure that the top priority is always the work itself, and that my perspective is always directly aligned with those with whom we am privileged to work.Function over form:
I believe that software is about what is done, not how it looks. Yes, it is important to build a reasonable (and, if possible, attractive) user interface onto the final result. But I truly believe that the vast majority of what matters is in the functionality. The great software giants, whether websites or desktop applications or embedded software or otherwise, succeed because of what their software does; the appearance does not truly tip the scales. Even Mac, which is highly focused on appearances, is fundamentally about making complex functionality into a simple interface, which is not about appearance, but about designing away the need for difficult user decisions.Get the content right. Then polish the form. The first step is far more difficult than the second.