I Want My Code to Be Boring

Earlier today, I was talking to my colleague Russell (@RussellScheerer) about some challenges we are facing with a conversion initiative.

In my case, I have been transforming a lot of legacy Adobe Flex code into services that will be eventually running within a Spring Boot RESTful service or as event-driven Lambda services in AWS.

Since Russell performs a majority the pull-requests (PRs) I submit on the project, I became intrigued when he told me that my code comes across as "boring" to him. I was taken a bit off guard from his comment. Before I could ask a follow-up question, he continued.

Russell noted that, for the most part, the logic I am submitting for review is strongly focused on business rules and functionality for the needs of the client. That he can understand, without a lot of unneeded comprehension or deep thought, what is happening in the code. He went on to mention that if he was in a production support role, very little time would be needed to understand and identify an issue — due to the ease of following the logic I have built.

Turns out, this was a compliment. I was proud.

How I Got to This Point

For me, I started with a great deal of source code in a language I had not worked in before this project. While there are aspects of JavaScript in the syntax, Adobe Flex and ActionScript were new to me when I first reviewed the code. When you consider the complexities that were achieved with the former application, the result was a great deal of custom code to meet the needs. After ten years of development and maintenance, the current repository had become very cluttered, with anti-patterns alive and well getting in the way of my ability to understand what the code is currently doing and what it is supposed to be doing.

On more than one occasion, I found where the code was not doing what it was supposed to be doing and the additional code was added to get things back on track. This was without making changes to the existing code that was the source of the issue. Clearly, there wasn't a full understanding of the existing code base. Basically, the code was "very interesting" ... the opposite of boring.

From the start, my approach to the services that I am building was simple. I was going to make the code as easy to read as possible, breaking the code into smaller chunks that can easily be understood and reused. Services would exist for a given reason and there would be a boundary established — where nothing else would live within the service that wasn't related to the aspect for which the service was intended.

I would embrace some of the newer Java approaches on the Spring Boot side, but would always keep readability and supportability at top-of-mind — right there with focusing on delivering code that is very performant.

Russell's Inspiration

I explained this to Russell, and he mentioned a video he had recently watched, which was part of the JDD 2018 conference. In the video, Tomasz Nurkiewicz (@tnurkiewicz) presents "Lessons Learned from Reactive Programming."  I suggest taking Russell's suggestion and watching at the 4:05 mark, which is where the video below should be positioned:

Being language agnostic, Nurkiewicz converts a common use case from a traditional language to a reactive style. It is quite amazing to see the reactive version, which leaves pretty much everyone in the dark on what the code is actually doing. Except, maybe the developer who created the code.

He goes on to say that our code should be focused on business logic. If we are in the insurance business, it should be talking about policies and underwriting, etc. From a code style, it should be boring. This is what Russell was talking about and it hit home to me. For this was what I decided to do after dealing with the mess I was given to build the new services from on our current project.

Looking Ahead in Another 10 Years

If you were to look at my code, aside from some Lambda functionality related to collections, most of my code is really not much different from the code that was written with Java 6 or 7. Well, we are doing some interesting things with server-sent events (SSE), but we have abstracted and segmented these items — providing an easy to use interface into sending, receiving and processing those SSEs.

An experienced QA team member can look at my code and figure out what it is doing. There aren't a lot of "interesting" things here, because doing so only adds complexity in a manner that is not really needed.

On the flip side, if I were to rewrite everything in a reactive style, I would turn over a series of services that would not be able to be supported by the production support team at the client. I would be introducing new terms and concepts that probably won't be popular (if even around) in 10 years. Interesting code tends not to last the test of time.

Instead, I should be focused on writing code that screams business logic first and design/approach last. 

I want to write code that is still boring, but very understandable, in ten years.

Conclusion

If you find yourself on the other end of one of my PRs, I fully expect you to yawn when you see the aspects of the Java language that I am employing most of the time. However, I fully expect you are able to understand everything that is happening. If your friend (who is a QA/tester) happens to glance on your screen, they should be able to understand what is happening, too. 

I want my code to be boring. I don't ever want you to say, "that's interesting." Because, every time in my career, my reaction is the same reaction that Tomasz Nurkiewicz spoke about in the video ... "that is a very bad sign."

"May you support an interesting codebase. A curse" - Tomasz Nurkiewicz

Have a really great day!