← Back to home

Solution scorecard

Calculator tool I use when considering different code solutions to a problem. Helps me consider trade offs.

This post has been archived.
This is a workspace post. It's a working document of my thoughts as I built something or pieced together an idea. It might be unstructured and contain spelling errors. It also might not look good on a small screen. But it could be useful to someone or related to another post, so I'm publishing it as-is.

Here's the calculator tool that I used to choose among multiple solutions to a coding problem. It's not perfect, but it helps me break down how good each of my options are. The most useful part is not the numbers it spits out, but that it forces me to carefully think through the numbers I put in.

I mostly use it when writing code, but it's helpful when doing UI/UX design stuff too.

Column headers are editable, as are cell inputs.

Ease: How easy is it? Clean: How clean is the solution? Understandable: How understandable is it? Extensible: How extensible is it? Logic v. Schema: Good balance? TOTAL 26 30 35

Here are some definitions.

Ease

How easy is it to complete? This one's a big one because any solution that is perfect on the other criteria but is impossible to do should tank the final score.

Clean

How clean is the solution? This is different than its ability to be understood. A clean solution might be easy to maintain once you understand it, but hard to understand it initially.

Understandable

Is the solution comprehensible to someone familiar with the problem? Is it comprehensible to someone new to the problem? A solution can score high on the other criteria, but be really hard to understand.

Extensible

How easy is it for someone working on this solution to extend it when they need to? If this is a one-off problem, or it's unlikely to be touched ever again, this might not matter. But odds are, someone will need to edit this block of code again, so it should be easy to change.

Logic v. Schema

The balance of how much of the solution is in the logic of the code, vs how much is in the schema.
Using the word schema here, but you could easily substitute for "framework" or "design pattern." If you lean entirely on the schema, you'll need to break it or move away from it when you need to write more code. If you lean solely on the logic of your code, you might end up having to write ever increasing amounts of it when you extend this solution.

workspace | code
2020-06-10