Foresight. Sometimes underplayed. Yet essential. Especially in the world of software development. But perhaps even more so in my personal world of ICTD software development in the field. Why? Because a 5-minute fix on the field has the potential to quickly snowball into a 5-day exercise in code restructuring. Because a 5-minute fix if left undocumented can quickly become lost in the annals of git commits.
So what exactly is foresight in this context? Perhaps the best way to describe it is thinking beyond your present needs. It involves thinking long and hard about what the target audience might want next – staying one step ahead of the curve. It involves diving into the mind of the next developer and thinking about what modularity they might find useful.
And then there’s the other side of foresight – losing track of the present. It’s actually quite a fine line to tread – balancing present day deliverables without being too short-sighted. Because at the end of it all, I am in the field, I am supposed to test new modules and leave the partner with something new at the end of the internship. But leaving the codebase in a position that someone else can pick up where I left off.
But foresight can only take you so far – if I could predict the future, I wouldn’t really call it foresight, which relies on expectation, some thinking and a lot of gut instinct. Sure, a few extra functions here and there are nice, but what can you really do to make sure the next person doesn’t simply demolish everything and start from scratch?
Here’s where foresight’s technical cousin – modularity – comes into the picture. It’s really quite simple, and if you think about it, a very logical way to go about work. C, the language my code is in, does not offer a high level of language-level support for modularity, unlike C++ or any object oriented program language.
However, all it takes is some smart design choices about what functions to put in which file, what data structures to expose and bake into other code and C quickly becomes a relatively docile beast. The main advantage of all of this is that when a part of the codebase becomes redundant or needs to be replaced, doing so involves a precision drone strike and not a cluster bomb.
And with that, I’m going to get back to my work – a lot of my foresighted code is in place but needs to be debugged before it can be user tested next week. What’s going to be special about this round of user testing is that it’s going to happen “in context” i.e. we’ll be taking SABTs to the classrooms to see how teachers and students can use it to enrich the classroom learning experience.