Too often when programmers are faced with a problem they immediately turn to code. Programming is NOT writing code, it’s formulating theories to solve problems. Solving problems requires thinking (up a theory) and analysing (your problem) PRIOR to actually implementing the solution.
In this post I’ll explain simple steps programmers of many backgrounds often forget, when starting new feature, component, module etc.
READ – EVAL – PRINT – LOOP, aka REPL, which us, functional programmers (or heck, folks with duck-typing languages), know rather well. Though, even Java 9 will have a REPL shell… 😉
is a terrific tool for exploring something. Whether you can parse incoming data this way or that way, if the idiom syntax was like that or not, if the library API allowed what you thought of right now… REPL is about quick and verified answers. It’s about moving forward (or stepping back to move forward in the right direction) easily.
REPL is there so you don’t put every idea you have in your code. How it works, for those who don’t remember or first came across the term:
- READ the input
- EVALuate it
- PRINT it’s value
- LOOP to 1.
So, let’s first explain how REPL fits designing software.
Tackle the right problem! Simplify the problem down to right metaphor, ask real questions, get down requirements that matter, find acceptance criteria that can help you. Gather your input well, or you won’t solve the problem. You’ll only write SOME code.
Some numbers say that 30% of failed IT projects is attributed to lack of or insufficient requirement gathering.
Choose points where you evaluate what you have so far. Plan for them, execute them, prepare for “not meeting requirements” marks and enjoy getting them. This is the moment where you NEED to fail, many times. Want to have feedback loop? First you need to have your work evaluated. You’ll find having more than one solution necessary: sooner or later you may need to switch between solutions or “merge / hybridize”.
Don’t spend too much time gathering data (READ), you need to EVALuate it every so often to move forward.
Communicate with others. Let them know your findings.
Later on, if possible, automate getting the evaluation results. Be it build/compile pipeline, CI, CD or end-2-end tests and client demo, have a clear and simple formula showing success or failure with obvious to grasp failure reasons / improvements required.
But when designing, show your new architecture sketch or diagram, compile a report on how the feature is used, that shows why change you lobby for is needed, etc.
The obvious step. Here you should place the usual in design looping. Milestones, iterations, coming up with system designs, tools, verifications and adjustments.
Why you need it? Because we all rush too often head-first. We’re all wired for shortcuts, we want to apply known and previously used patterns. We’re all impatient, guessing what the other person will say even before she completes her sentences, applying our own filters, preconceptions and notions on someone else’s ideas and words. And this often works, but when you write software it often ends up to be rushed “too much”. So, here is a “framework” for design, to help you avoid that.
Why REPL? Because it’s known acronym, with clear associations and usages. It verifies (evaluates) ideas, quickly. It communicates (prints) results, also quickly. And it proceeds onwards, one idea (input) at a time. And designing is very similar. Feel free to use design REPL one requirement at a time, one acceptance criteria at a time. Go back to those that have changed. This helps tackle large problems by decomposing them into small ones:
- READ problem description and requirements. Define word meanings.
- EVALuate them, try quantifying them. Along the way discover need for more data, more exact requirements, acceptance criteria.
- PRINT your results so far, announce next steps.
- LOOP to 1, adjusting what needs to be adjusted, setting next goals, delegating tasks, requesting more information or help.
Because everybody knows that “you need to gather requirements”, “your requirements need to be quantified”. Everybody heard the question “how fast is fast?”. But apparently, that ain’t enough to do design well. Or I’d have seen much more great software around us. 😉 Which I hope to!