I love technology and my work has never been quite enough to scratch that technology itch. I have always got at least one home project in progress and normally several on media centres, networking, home automation, security, or robotics. I have been wondering what are the parallels between the one man hobby development project and the commercial world of development? How similar are these?
My time for hobby development is limited and precious. I want that time to be spent making the most progress to my project goals. Issues getting my development environment to work, finding old code to clone or network instability are frustrating as they erode this time. I’ve had some wasted weekends where it has taken me hours to find some project code to reuse from a few years ago, only then to realise I can’t remember the magic spells I used to get it to run.
Issues like these made me realise I needed to think carefully about my development environment and setting up the development lifecycle and tool chain. I started looking at the Raspberry PI PICO MicroController this year for some of my more hardware focused projects (servo, fan and LED display control). I took the time to build a standard project structure, makefile and version control repository. Made sure that I had shortcut scripts to run up the debugging environment. As well as following good Test Drive Development strategies as talked about so well by my old colleague Dave Farley on LinkedIn.
I even recorded my approach to C/C++ development setup for the Raspberry PI PICO into a course on the Udemy platform (https://www.udemy.com/course/introduction-to-c-development-environment-for-raspberry-pico/?referralCode=875319E04F95C9EC3414). In publishing it I hoped that others could get a head start to focus their time on project goals rather than the flaky tools and environment.
In the corporate world time is also precious and progress towards the outcome of the project is the measure of success. With the same challenges both environments need the same solution of well managed development environments and tool chains. I think the only difference in the commercial project world is that we often have specialists to setup the tooling and put in place the development strategies.
The other big drain on my time for hobby development is operational issues. Fixing devices and systems which have died. These might just need a reboot, a tweak because an internet service has changed it’s protocol or keys have expired. I recently lost lots of time when my farm of AWS IOT devices had a string of failures with devices dropping offline each day. I scratched my head as to why the number of dead devices was growing and nothing had changed. After a couple of weekends of lost time I discovered I had put 18 months on the key life, and they were now all coming up to expiry. Security works but my diary is lacking in reminders!
In a one man hobby environment I have no operations which is similar to a DevOps teams in the corporate world. I see DevOps as having the same desires to reduce operation load to the minimum to allow the majority of work to be on forward outcomes. We need principles on system reliability and lights out operation. So systems need to alert on failure, though the same alert strategy so it is easy to pick up on failure and hopefully route cause. Where possible systems should be self healing for at least common failures, for example the most common in a home environment is recovery from an Internet Service Provider outage.
This is all sounding very similar between the one man project and the corporate team. Surely in documentation we must have very different strategies?
Documentation is primarily there in the corporate world I think for communication. That communication may be during the project to share knowledge or across time to act as a corporate member. In a one man team communication is minimal. I will confess I talk to myself but I am not sure that counts as communication.
My experience is that in the hobby one man environment I need to take more notes and jot down more design patterns than I would in the corporate world. It may not be as structured into deliverables as a corporate project. This need for greater notes is driven by the wider breadth of skills being used as one man does all the roles. Each role and tool is not a full time job and therefore I don’t become as prolific an expert on each tool as I would be in a bigger team where one could take a more specialist role.
Documentation does have a different role in the hobby project. Though I don’t think it is as significantly reduced as one would first expect.
I’ve only touched the surface of this subject considering whether our priorities are the same between a hobby developer and a commercial team in a DevOps model. It seems to me that proprotoes across the three dimensions I have considered are very close though not identical.
- Have an efficient environment focused on development and not tool issues
- Minimise operational overheads and allow focus on the next project/feature
- To maintain a knowledge repository to maintain and extend system
