I’ve often thought about whether I should write about my experience working in the government, but I don’t think I would have much to add, other than my own user stories, to Jennifer Pahlka’s Recoding America. The book does a great job of capturing the trials of working in digital spaces within the US Federal government. It clearly describes the issues ranging from the laws that have been created, the regulations that limit, the processes that obscure, and the frustrations that occur in trying to create services while working in the government. Also, it has some very insightful footnotes and anecdotes.

Here are things that really resonated with my experiences:

• Unintended consequences of laws that have been passed and how they can or cannot be interpreted.
• Use of waterfall project management regardless of the project or if it is relevant.
• A lack of expertise in modern software engineering (or data science) practices.
• Procurement processes that focus on requirements rather than results.

The discussion around risk and requirements seemed very relevant. Oftentimes, projects or services have to be developed to account for every possibility that, in the end, means that almost no service is delivered (in reality or practice). This is often due to the lack of flexibility in how a law is written rather than what the intent or spirit of the law is. This can be due to how a law is written, how it is implemented, who is implementing it, and who is interpreting it. This is also an area that could be its own course on how to balance risks and requirements and results.

In terms of solutions presented in the book, there were two that seemed most valuable to me: (1) the involvement of those with more digital expertise in crafting laws and regulations, and (2) prioritizing product owners in federal staffing and projects. I think both of those would help to improve processes.

Another takeaway for me is that it does have to be someone’s job to fix and improve things, and that person needs to have some authority or a voice with those who have some authority to make sure things are fixed.

It would have been nice if there was a silver bullet that would just make everything easier. But the book does a great job of outlining why there isn’t one. It is a complex problem involving many different layers. While there are some techniques to make some things easier (Agile vs. Waterfall), it is still a problem that involves people. There are some great examples of people who are able to succeed, and they are able to do so through building trust from successful projects and building relationships. If anything, the importance of trust is something that could be further emphasized as I’ve found that to be key to the success of projects.

The book was thought-provoking enough that I could write more about it. This probably would include any additions based on my experiences. When I have a chance, I should share my work on software licenses would probably be a great user story outlining all the different things that need to be done in order to improve something for those working in creating software as civil servants. It fits very much into the themes and stories of the book.