OhPauleez // Paul deGrandis

All engineers, regardless of their field, should strive to do one thing: solve problems.  Your goal should always be to thoroughly dissect problems, organize the necessary information and solutions, and deliver a working product that meets all requirements.  Simply put:

Deliver well-founded solutions that say something.

 

Much literature exists on solving problems,¹ and my goal here is to tailor some of that knowledge to software engineering.

The phrase I presented above rightfully seems simple and intuitive.  It concisely lays out the ideal mantra for all software engineers.

Deliver

Constantly focusing on having a working product will ease integration pains and guarantee that you always have something to deliver to your customer.  Performing tight iterations upon a working product often makes it easier to reason about and navigate solutions in problem domains.  By doing so, you’re able to map iterations to small isolated pieces within the problem space.

Well-founded

Your solutions should strive to build upon the knowledge and experience of others.  Use and compose proven strategies, techniques, and architectures.  When possible, map artifacts and intricacies in your problem domain to those in other domains with elegant,² established solutions.
Collect and document previous approaches and solutions to your problem, as well as to any analogue problem.  Critically analyze all solutions, including your own.  You’ll be able to constantly review, refine, and repair previous solution areas as you work in tight iterations and constantly grow your knowledge-base.

Solutions

The abstract concept of a solution is interesting.  Given a solution, you expect that it meets all the requirements of a given problem, but you’d also expect that there were some tradeoffs within the solution space.  The ideal solution is the one that doesn’t exist.  That is, a solution so complete, subtle, elegant, and free of tradeoffs, that it completely removes the problem in its entirety and doesn’t introduce any additional problems.  Sadly, all the easy problems are solved, so this is almost always impossible, but you should still strive for it: a working solution that meets all the requirements, minimizes tradeoffs in the solution space, and doesn’t introduce any new problems.

… that say something

Tests and metrics should guide your solutions.  Seek out or provide hard evidence in your analysis of other solutions as well as your own.  Your tests and data should efficiently and completely verify and validate your solution, providing empirical evidence (or theoretical evidence where appropriate³ ) that your solution is the best.⁴

You should drive this process by the requirements⁵ and specifications that fallout from decomposing the problem space.  You should drive the composition of your solution by its architecture.⁶

1. Polya’s How to Solve It is regarded by many to be the canonical reference for decomposing problem spaces, documenting them, and coming up with great solutions.  It’s a book that should be on everyone’s shelf. [↩]
2. This is a rather loose use of elegant.  You can take it to mean how completely a solution fits a problem, with the minimal amount of side effects incurred. [↩]
3. A good example is information retrieval.  There is a lot of math that is useful to prove theoretically optimal solutions for things like real time search. [↩]
4. I’m using best here to mean achieving the same or more of the requirements of other solutions and doing so with introducing fewer side effects, tradeoffs, or additional problems. [↩]
5. Both nonfunctional and functional requirements.  The former is often ignored or assumed. [↩]
6. The cheapest place to find bugs, inefficiencies, and the easiest place to rapidly test out and evaluate an idea is in design.  While software architecture is a process that should be carried on throughout a project’s lifetime, centering your design work has a lot of advantages [↩]