Open development experiment: reflection and conclusion
In the previous post I defined the ordering function and found an implementation I could reuse. This was both good news and bad news: good news because someone else had already done the work of implementing an ordering function using a Feistel network, but bad news because I didn't get to have some fun writing bit-twiddling code.
In this eleventh and final post of the series, I'll reflect on the outcome of the experiment and also on what I've learned about truly open development.
Admittedly the experiment was small and bounded. But it was also non-trivial and interesting. The outcome was a fairly typical trade-off between writing new code and reusing someone else's.
What were the downsides of reusing another implementation?
Apart from not getting to write more code, the main downside was that the code wasn't quite what I would have written myself. The code was clean and understandable and had good documentation.
But I wouldn't want to ship code that panics when presented with invalid inputs. An interface is often used quite differently from how I expect. If I make sure that error handling is explicit in the interface, then it encourages all code calling the interface to handle errors suitably. The using code might panic, but at least the panic will point to the code that needs fixing.
That said, I was able to wrap the code in a clean interface that returns errors rather than panicking. That was fine because my performance requirements weren't too exacting. A URL shortener would call the ordering function just once per request to shorten a URL (and wouldn't call it at all when mapping a shortened URL to the original URL). There's a little extra complexity in maintaining a wrapper, but not much and certainly less than maintaining the ordering function itself.
Then there was a part of the code that I didn't understand: a test that the permutation was pseudorandom. I spent a while searching for information on testing pseudorandomness in terms of a triangular distribution, but couldn't find anything. However, this test is unlikely to cause trouble. In the worst case, it might fail if the permutation implementation was changed significantly. But in that case, the project owner would almost certainly change the test to make it pass.
What were the upsides?
The main upside was having a clean implementation with good documentation and decent tests, but with minimal effort.
Also, if I'd written my own code, it may well have remained a solo effort. But by reusing someone else's code, at least two pairs of eyes have looked over it carefully.
Then there's maintenance. If bugs are found, there's a good chance someone else will fix them. Maintaining my wrapper would be very straightforward. I'd just have to decide if and when to bump the dependency to pick up changes.
I also felt I added a little value to the reused code by proving the correctness (see the previous post) of part of it which wasn't obviously correct (at least to me).
What about the experiment as a whole?
I enjoyed the process of writing up my thinking as I went along. I don't mind working quite slowly on projects these days as I'm doing them for fun and personal satisfaction rather than for an employer and on a schedule.
Parts of the process were quite tricky to write down in real time. When I was mulling over the requirements and design, I had to force myself to write down some things that would turn out to be dead ends. If instead I'd written just one post after the project was complete, it wouldn't have had so many lose ends. But hopefully that gives readers a more realistic impression of the way I work.
Insights into the way I work
I go off on tangents occasionally. The commit history of my code describes just a small part of my development process. This was always the case throughout my career. My goal was to grow my understanding and skills as well as deliver working software. This approach helped make even the dullest piece of work enjoyable and thereby helped me do it well.
Going off on tangents is also about the way I learn: I need to explore aspects of a problem that interest me. I find skipping over things I don't understand deeply unsatisfactory. I guess that tended to take the edge off my raw productivity, but it also increased my longevity.
Would I repeat the experiment?
Probably not. Although I tend to write stuff down as I go along, I wouldn't necessarily want to polish the material for publication. In fact, I think going back to using a physical development notebook is preferable. The ability to work in pencil, draw rough diagrams, scribble questions, and jot down half-formed thoughts is a great freedom compared to writing up my thoughts coherently for consumption by others.
Conclusion
Working in a completely open way — by which I mean publishing my thinking as I go along, as in this experiment — certainly influences the development process and the ultimate outcome, but I'm not sure these effects will always be positive.
The extra time investment represents inertia that could reduce the chances of switching to a better design or feeling free to make certain kinds of improvement. Perhaps a sweet spot would be to keep notes as I go and use these as the basis for a blog post if that seems appropriate.
Feedback: email me.
