Dogfooding Development Lessons

Checking that I’m walking the walk for the talk I talk.

Dogfooding is using your own products to see how well they work. The phrase seems to have started with Mars, who make more pet food than chocolates. Their corporate heads, try the food before they feed it to their own pets.

For six months or so I’ve been rebuilding a mobile app for a start up. Unlike everything else I write about, this is just me. This is a team of one. Me. I’m solo. It occurs to me that while I’m applying team collaboration aspects to my solo work, I’ve also neglected a few obvious ones. This post aims to fix that. I find that writing helps me think.

These ten collaboration rules are what I normally propose for teams to work together.

1. Always be collaborating, instead of working on your own
2. Aim for diversity to improve your work
3. Work in the open so the team can see your work sooner
4. Be humble and ask for help and feedback
5. Meet regularly with a suitable cadence for your context
6. Accept that it’s all guesswork and start small to learn more
7. Build deployable small vertical slices to learn more quickly
8. Keep doing the next riskiest item in order to reduce risks quickly
9. Shorten your feedback loops, so that you learn faster
10. Always be pausing to review your collaboration

As I’m doing this work on my own, I’ve tried to follow the obvious ones. What surprised me recently was that I’d overlooked other aspects, which would help me.

Always be collaborating, instead of working on your own

Working on your own sucks. You have no one to turn to and ask a question.

Go solo for now. Add people later. This means it is slow at the moment. I have realised there are times when I would’ve gained understanding of the issue/challenge if I’d talked it through with someone.

My next step to remedy this is to find a user-group, or community meet up so that I can discuss these issues with other people.

Aim for diversity to improve your work

Homogeneity means more of the same. We need different perspectives to improve what we’re doing. 

As it is just me working on this, I only have my perspective. The closest that I get to other perspectives are what I read after searching the web, for what other people are doing in this situation. This also provides some background to what I’m doing, and guides me in other aspects.

As I’m on my own, this is sort of like the literature review that students do on their dissertations. I’m reading around on the topics, and seeing how those aid the development. This is much slower, than if I had a partner, who was pairing with me on the work.

As above, the remedy for this would be joining relevant meet-ups to gain other perspectives on ways to approach the work.

Work in the open so the team can see your work sooner

When you hide your work, no one knows what you’re doing. They can’t say that you’re going in the wrong direction.

This is a problem when doing solo work. As I’ve been rebuilding something that was there, I’ve not been showing my work to others. I’m reporting progress on various challenges: getting menus to work, setting up database connections, and fighting with libraries, aiming to put in place something similar to what was there before.

My goal has been to learn how to do various tasks, so that I can repeat them on other screens. Showing my work to others, when there are no others means I am working in the dark in one sense.

This ties in with the previous two rules: as I’m on my own, and I only have my perspective, plus what I read about, I’m not benefiting from feedback on the code. I might be making mistakes, or building up technical debt, which will come due later. I don’t know. Hopefully not, but I don’t know until I read more, and build more and see what happens.

I’ve changed a few things along the way so far: reorganised the database calls as I learned more about the framework’s rules, shifted things to utility objects, to make the code more usable. These happen as I learn more while doing the work.

All of this is happening in one branch. This is trunk-based development with lots of small commits. Really small commits. Sometimes every ten minutes or so as I complete each step towards my larger goal. I really don’t want to lose my work, and I know that I can always revert a step if I go in the wrong direction. Yes, that did happen once. 

To make life easier for whoever picks this up at some point, I’m leaving lots of notes in the readme file. This explains my approach, has links to libraries, and other references to concepts. Some comments are also there explaining why/how new additions should be done, and what some error messages mean, and how to fix them.

I can mitigate the risk that I carry too much in my head, by keeping the readme file up to date. It is as much for me, as others, who follow later. Writing it out helps to clear my head too, and clarify my thinking.

Be humble and ask for help and feedback

None of us know everything. We all make mistakes.

Now that I have resolved most of the technical issues, I need to start asking for more detail on what follows from the others in the start up. This is partly showing what’s working, as well as, clarifying what is required for the remaining parts. This will also be a process of story mapping at some point, to see how we might start with a small feature, and then grow it over time.

When working solo you can ask lots of people for feedback. I know that I’ve discussed some aspects of the work with developers/coaches, and other agile people in random coffees. I suspect there would be be value here too, in discussing work in general with people at a meet-up.

Meet regularly with a suitable cadence for your context

Yes, meetings can be dull and unhelpful. We do need to keep in touch with where we’re at, and in-person speeds up communication too.

As mentioned above this is being done as a series of small, very small, thin slices of work. The goal is to complete a part, or if lucky, a component in a day. This makes it easier to stay focused, and think about the next steps between sessions.

When working solo, I’ve found it useful to have a rhythm to my week. This helps me plan what I intend to do each day, and work out when I should aim to do longer, deeper work, and when the small, less exciting tasks can fall into place.

Accept that it’s all guesswork and start small to learn more

Students are doing these things for the first time so it’s all new. 

I’m not using estimates. It’s all guesses, so I just start with the first small step, and then move onto the next one. The goal is to do this as soon as possible, but it also needs to be done in a quality manner. This takes time, and patience, which will pay for itself later, when it is easy to add more features.

As a solo developer, the learning is the important part for me. The others in the start up know what I’m doing, and are curious about when it will be ready. They also know this needs to be done to a good standard.

Now that key learning is in place on how to put the rest together, it might be possible to consider a possible timeline. I would also express it as a range of dates, when phases might be completed. The purpose, here is to facilitate business planning.

Build deployable small vertical slices to learn more quickly

Your client wants to know where you’re at with the thing you’re building for them. Show it to them early and often.

This is an exercise in thin vertical slices. Each part contributes to the whole, and adds to it. Sometimes near the end of a slice, the commits are refactoring, because I learned something new, or noticed repeated code. Each of the thin slices, however, are always a visible change.

Whether you’re working solo, or in a team, thin, vertical deployable slices are more workable than bigger chunks of work. This is always true.

Keep doing the next riskiest item in order to reduce risks quickly

Risks need to be addressed or they will not be reduced. Assumptions are just as bad.

This project always had risks. There is also risk in our work. My goal has been to remove them steadily one by one as I learn how to implement different features: navigation, database, charts, etc. There are also testing risks too: how to ensure testing can be done as unit tests, and integration tests.

With the main ones resolved, new ones will soon appear too with deployment and live testing, as well as logging in production. The goal is to keep reducing these, and mitigating/removing new ones as they appear.

Reducing risks makes sense when working solo and in a team. Use the ‘next riskiest item of value’ to guide your work.

Shorten your feedback loops, so that you learn faster

Without feedback we don’t know if we’re doing the right thing.

I’m always looking for the benefits of early feedback. Working solo, this often means ensuring testing works well and is possible.

I’ve also learned that testing allows some playfulness to enable observability without having to build the whole. This was new to me. I could write a method to try out an idea, or explore how to write something to gain insight without having to build the whole: I could try small pieces of code to see the values returned, and then throw it away once I knew what I needed to use.

As solo developers, we need to look for a variety of feedback from where we can. This should be in tests, talking to people about our work in general, and in more detail where possible. We should also show it to other relevant stakeholders when and where possible to aid with development and planning.

Always be pausing to review your collaboration

Retrospectives help us improve on our work.

We never know everything. Pausing to think, and consider other options, and then trying them out helps us move forward. That’s part of what this post is for. It’s me thinking through these things, to see what I might do in order to compensate for my solo working pattern.

This applies to those working solo, as those in a team.

Revised collaboration rules for solo developers

It looks like some of the collaboration rules work whether you’re in a team, or on your own.

1. When working on your own, look for other people you can talk to about your work.
2. As a solo developer, you need to add diverse opinions, and ideas to improve your work.
3. There are other stakeholders, so keep your work open to them, so they can guide you.
4. Be humble and ask for help and feedback from other stakeholders, and others who can offer ideas.
5. Set a suitable cadence for your work to enable deep thinking and work, as well as smaller tasks.
6. Accept that it’s all guesswork and start small to learn more about your domain and context.
7. Build deployable small vertical slices to learn more quickly.
8. Keep doing the next riskiest item in order to reduce risks quickly.
9. Shorten your feedback loops, so that you learn faster.
10. Always be pausing to review your collaboration.

This works for me. I see that I have some more things to try to grow my network of people, who I can talk to about this work. It might mean more time away from doing the work, but it will also aid me in the long term.

If I were to apply this to teaching computing students, then I would point out how these apply to their own solo work. Depending upon the assessment, there would be some scope for discussion about how they are approaching their work without moving into collusion, or plagiarism. Obviously, they can’t show their work to others either.

Where do you think you can make some changes in your work to gain more from this sort of thing?

---