About

My name is Christopher Bojarski. I'm a web developer, programmer and blogger. Fan of all things technology related. Avid reader and traveler. Married and living in Philadelphia. Connect with me at cbojar.net.

Popular posts from this blog

Untangling Nested Code

Image
There is code out there that is ugly. I mean really ugly. I know, can you believe it? But it's true. One such example of really ugly code is code that has lots of deeply nested calls. The tests are trying to test a dozen different methods in every case. The methods look so simple with just a few lines and a few calls. And then those methods called have a few lines and a few calls. And then again, a dozen or more different calls deep.

We want to use private helper methods to make our code clearer and cleaner. Calling methods is also largely what programming is about. But sometimes we overdo it. Deep call hierarchies are difficult to follow and they can mask what the code is really doing. Each call means that we have to look all over a class to see what actually happens. This makes debugging hard. This makes testing even harder.

Say we have the following code:

class DataLoader { void loadNationalData(Nation nation, int year, DataReader reader) { for (State state : natio…
Read more

Typing != Complexity

Developers of all experience levels commonly share a false belief: more typing means more complexity. The most powerful idioms and tools often require a few extra keystrokes, but dramatically reduce complexity.

The final keyword in Java is a bit of extra typing. The final keyword can be applied to variables, method parameters, instance members, static members, methods, and classes. By making these final, their values will not depend on their context. They will be known constants through their lifetime. Their constancy removes a large cognitive load. The developer no longer needs to worry if the value was not set or if it was set multiple times. Many developers forgo this benefits to avoid typing the extra keyword, to their own detriment. Later, they spend too much time chasing down defects caused by mutable state.

Developers will often shun creating small types and interfaces because of the extra typing involved. Interfaces can abstract away many different implementations behind a sim…
Read more

The Cohort of Responsibility

Sometimes the team just isn't enough.

Delivering business value from idea to production is a complex endeavor. Development teams sit squarely in the middle of that process. Ideally, they are talking directly to the customer. Often in real life, business analysts collect requirements from customers and pass them to the development team. On the other side, development interacts with operations to deploy and run the software.

All of these groups, and more, have the responsibility to deliver the business value. But too often, there is friction between these groups on the path. Not everyone wants to move in the same direction. Some individuals or groups can slow down or altogether stop value from being delivered. They are responsible, but not always accountable.

Everyone who bears direct responsibility toward delivering business value is part of the Cohort of Responsibility in the organization. To most easily identify everyone in the cohort, we can pick out everyone who must touch a re…
Read more