Many people think the purpose of software development is the software. No. I think the purpose of software development is a better understanding of the problem. Our users, clients, customers might have a problem, and we, the developers, need to find a solution.
Certainly, writing software could be a solution. Often it solves a part of the client's problem, while introducing new challenges. Documentation, process improvements, tutorials, blog posts, training sessions - these all could be better solutions to the client's problem than writing a new software feature. Thus I think the absolute emphasis some organizations put on code commits and features, while ignoring the other types of output, is a misguided and self-limiting approach.
The relative benefits
I often "count" how many benefits we can get from working on the client's problem, and how much long-term value we can derive. Here are my rules of thumb:
- if we write private code to be deployed, then we get 1x benefit. The code might solve the problem, might not, we often do not know very well until the code is done. We might get paid for writing this code though, but it will also cost us to maintain the code.
- if we write any internal documentation for our own practices (think an internal company wiki), we probably get 0.1x benefit from it. Maybe at some point this wiki will help us write software for the client, but maybe it won't. Internal documentation requires maintenance, thus it will cost us. I guarantee that wiki will get out of date and will be confusing to the newer hires. Thus I rate private wikis very low and do not contribute to them anymore.
- writing public blog posts describing good development processes, or problems solved, or how-tos I would rate at 5x. Because you get multiple benefits from this:
- you investigate the problem, thus your understanding increases
- you write better because the final result is public. And I always do a better job when the results are public rather than private
- you raise your own profile by writing about the problem, attracting attention and building your reputation. This is a nice benefit that allows employees to advance in their careers
- you bring the search traffic to your blog. Some companies pay external developers to write articles about everything under the sun just to get that search traffic, see LogRocket blog and BitSrc.io
- speaking on the subject at a meetup or a conference gives approximately the same 5x benefit in my opinion. A conference talk might have a strong boost, but I believe it is short-lived compared to a well-written article, and the SEO on the article is stronger. But the preparation for public presentation requires definitely a deeper understanding of the work you have done
- every blog post and public presentation relevant to the company's software should be linked to from the documentation. Some people read the docs, some people learn better by reading tutorials, some people love watching a video of a presentation - give users all possible ways to learn, while exposing the work to more eyeballs
- making an open source tool solving the problem well enough gives 10x benefits
- the work is typically of higher quality - again, because the code is open for everyone's criticism and inspection prompts its authors to make an effort
- the project can benefit from input and work of the people from the open source community
- the code might be reused multiple times, bringing your own developer value to the cool $1mil
- by the way, open source projects can benefit from a free infrastructure provided by code source hosting companies (GitHub, GitLab), continuous integration (no need to pay for your own Jenkins torture device), testing and hosting services, etc
- short term exploratory projects commonly called "spikes" are 0.5x - on one hand they help us understand the problem better, but often I do not see any tangible output aside from a single developer getting a better understanding of the problem or its possible solution. This benefit is short-lived; the developer forgets, or moves to another organization. Make sure the spikes produce a public blog post, a library, an update to documentation, something tangible.
Wait, how can open sourcing code bring more benefits than selling the code to a paying customer? Well, in my experience, few customers require exactly a single piece of code. Most of the time, making a successful business is 10% "special sauce" code and 90% of-the-shelf code ... that does not need to be private. And thus we can safely open source that 90% of the code, get the benefits I have described above, get public recognition, etc. etc.
An example
This is how I translate the above list into practice. Recently, I wanted to find for sure if some Cypress recipes randomly failing on CI had a real flake in their tests. Normally debugging a failing test is a time sink, right? No if we derive some benefits from this work.
- I wrote a script to run the project again and again. The script, although public, lived in the recipes' repository and was not reusable. 1x benefit, since it was not reusable and no one could easily benefit from it in the wider community.
- By using the script I did find a bunch of tests that had problems in their timing and fixed them. Nice. Even wrote a new section for the blog post Working with Select elements and Select2 widgets in Cypress. Extra nice.
- Then I thought about the script and how to make it into its own open source project. To make it into a general
cypress runwrapper I needed to parse the command line arguments people might provide likecypress run --browser chrome --record --group frontend ...the same waycypressdoes it. Thus I added it as a feature to Cypress itself. Ok so far probably 1x benefit. - Once the CLI parsing was released (benefitting any user who wants to write own Cypress wrapper), I created cypress-repeat and cypress-expect - multiple benefits from my original effort that accrue to both Cypress and to me personally
- The same logic I have shown could also be used to implement @cypress/percy module to avoid launching a child process, since now their wrapper could parse its arguments separately from Cypress' arguments. This strengthening of Cypress ecosystem brings its own benefit, let's say 1x
- The same wrapper could also be used by the CI providers like AWS Amplify in their integration of Cypress Dashboard with their own project web UIs - another 1x benefit
- Finally, I have written a blog post about different ways to use Cypress NPM Module API in Wrap Cypress Using NPM Module API. This blog post can be shared, linked from Cypress documentation, etc. It could become a topic fo a future webinar presentation or a meetup talk.
Simple software, but I derived multiple benefits from developing it.
Bonus 1 - Discover benefits
I use the following questions to never "leave" benefits on the table. Click on the question to expand the benefits details.