This morning I opened a shared library that I started a few weeks ago. It was broken. But the tests are green. Take a deep breath, I tell myself at least once a week. This is your corporate life now. Let it go and let them learn.

Update (19.04.17): it turned out the library was not broken, but rather the “output” code, which I viewed as a sort of integration test. There’s still room for improvement and refactoring. But I jumped the gun and apologize for my premature criticism.

My employer is in the midst of an IT transformation. My current teams work in a “startup” environment on internal projects sheltered from headquarters and bureaucracy. We’re (supposed to be) agile. The first few months were exciting and fun.

When I had problems, I assumed it was because I just didn’t understand the complications of enterprise software. Senior developers said that’s how it’s supposed to be. I accepted their answers and let my own insecurities suppress my gut feelings about code craftsmanship. This is the corporate culture I live every day. And I choose to stay because I want to change it. But that can mean letting go and not fixing or improving things, especially ones I started - however counterintuitive that sounds.

When I quit self-employment and startups to join an enterprise, close friends were surprised… a few even predicted I would quit within a year.

Jumpstarting Responsibility

I started the library because we needed something. After weeks of side discussions without any results, I decided to just use an open-source library and start the implementation myself. In our corporate world, adding a new technology often starts with questions about how to avoid it. Can another team in headquarters handle it? Is there existing vendor software for that purpose? Teams would rather add a hard dependency to business processes and bureaucracy where they have no control than to take responsibility and do it themselves.

In retrospect, I alone made a decision for the team, which was bad. But on the other hand, I have forced them to try something new, which has been eye-opening on both sides.

In the corporate world, adding a new technology often starts with questions about how to avoid it.

Some team members quickly understood what I was trying to achieve and saw the immediate benefits. I setup the first layer of abstraction on top of an open-source library. With the technical abstraction complete, they just needed to apply it to the domain and create an API. Simple, right? Nope.

I figured I had 2 days work left when I handed over the library to other members of the team. I pair programmed with them for 2 days on it. A week later, the library is still incomplete. And it’s broken. But the tests are green! That makes me both cry and laugh at the same time.

Don’t Avoid Problems. Anticipate them instead.

I am writing this post to avoid rolling up my sleeves and fixing “my baby”. If I were to jump in and fix it, I will undo the most important thing I’ve done in the past 4 weeks: jumpstarted responsibility. We’re building something ourselves instead of going to headquarters or a vendor because we want to release by the end of month not in 6+ months. I hope we are learning to believe how fast agile can be.

Of course there are risks. I expect headquarters to knock on our door with complaints. I don’t avoid them but rather anticipate them with a plan. When the complaints arrive, as a team we will have:

• launched our software.
• delivered business value buying political currency to go through HQ processes faster than 6+ months if we are required to do so.
• learned how building your own software affords flexibility.
• realized that maintenance is low if you build good software.

For someone who was 2 years ago self-employed and counting invoices in terms of rent, that is not risk. But almost all of my colleagues think differently. I’m still not exactly sure what they are afraid of. But we’ve identified responsibility and risk as a theme. There are many barriers to IT transformation in a corporation. Some like code quality and craftsmanship can be addressed with training. Others like culture can be more difficult to change.

That is true on both sides. The feature isn’t complete. I will bring up the topic of false positives in testing. But I should let them finish the feature before I criticize and refactor.

The Next Challenge

Last year when I quit self-employment and startups to join an enterprise, close friends were surprised by the extreme switch. A few even predicted I would quit within a year. It has been 10 months since I wrote Employed Again when I was on a high from being a part of a team again. Surprisingly it has not been bureaucracy that has been most frustrating the past 6 months but that very team.

Yet I am still here. While there are moments when I want to cry or laugh in desperation, I am thankful for the opportunity to dive into software architecture and take an active role in IT transformation - my biggest challenge to date. I’m in it for the long haul. So today I need to let go.