This is a concrete strategy to keeping uncertainty at bay.
One way to build programs is to write a lot of code up-front, and then to see if it works, fix the bugs, iron out the problems, and submit the PR. This is a poor way to build programs, because all written-but-untested code carries with it an uncertainty of whether it will work correctly or not. The more such code there is, the more (multiplicatively) such uncertainty there is. And the more time passes since you typed the code, the less fresh it is in your memory. So when you write a bunch of code up front, and then try to run it all, when it fails to run (as it most likely will), it is laborious to find the bugs. Too many possibilities — is it in this function, or that function, or in how the functions are plumbed together? What was this function all about, it’s been a while since I wrote it? You’ve bred a lot of uncertainty, and now have to deal with it.
The opposite approach is to get to runnable, and thus testable, code as soon as possible. For anything but a brand new project, that’s the default state anyway, unless somebody broke the master branch. From there on, structure your development process in such a way that you never code for longer than ten minutes without running the code. This way, you have at most ten minutes of code worth of uncertainty to deal with. It’s all fresh in your mind, so finding bugs is quick and efficient.
If you are new to this style of development, it may take some adjustment. In particular, when you have this whole new feature to build, how can you test it until the whole thing is built out? Stubbing is the answer. Provide stubs for new pieces of code, and then iteratively replace them with real code. For example, if you’re adding a new UI component, just get this up on the screen:
<div>Hello!</div>
Does it render? Great! You’ve just wiped the slate clean, removing a whole bunch of uncertainty associated with plumbing/glue code. The component is usable. Next, just dump the props as a JSON string:
<div>{JSON.stringify(props.data)}</div>
Is it showing up? If not, reasons for failure are quite limited, and thus easy to debug. If yes, great, now, small steps at a time, build out the contents of the component, testing all the way.
This bite-sized development that keeps uncertainty minimal is very efficient. It also works well with the “implementation tree” approach introduced in organize your execution.
Comments
Post a Comment