Defy the Status Quo – Innovation Under Constraint

Throughout my career I have received the following critique when asking about why I was not advancing. “You are a great programmer, but you don’t know the business”. I feel that this is valid criticism and I took time to think about why this was the case. Three reasons I found are:

1.      Companies focus on technical skills only during the Interview (my tech skills get me in the door, not my knowledge of business)

2.      There is rarely any training on business processes when you join a team (you are forced to learn it on your own)

3.      Many developers learn by reading and analyzing code (legacy code doesn’t always make this an easy task).

Earlier in my career I was put on a team tasked with upgrading a legacy system to add support for additional business processes. My first task was to read the existing code and try to “Reverse Engineer” what it was doing. The pain points in the legacy system were:

1.      Fear of making changes to code. Too many times a change in one area of code would cause an error in another area of code.

2.      Business logic was present everywhere in the code. Database calls were being made from the backend code and the UI code.

3.      Only one person who worked on building the code is still working for the company.

After taking on the challenge to “Reverse Engineer” the legacy system and build a new system that could support the additional business functions I was all set to architect a domain driven solution that followed SOLID principals and had full separation of duty.

And then I ran into a major ROADBLOCK. My manager at the time told me that I COULD NOT separate the business logic code from the database code. He didn’t want to have to deal with the different layers. This went against what I knew as a best practice, but I set out to do the best I could given this CONSTRAINT.

At the time I was learning about Fluent Coding using Extension Methods in C# and I realized that I could make this code simple to read, understand, and update. Most importantly I could write the code in plain English so the next person to work on it could easily understand what the business process was.

I will omit an example of the legacy code that where there is a method that contains an extremely long “hard coded” SQL query to pull a list of objects. However, I will show how I was able to encapsulate that logic into easy to read code blocks.

The following code is pulling a list directly from the database layer and breaks down the query in plain English. This is ultimately the minimum a new programmer needs to know.

Next I implemented a pass through method for the database to filter a database table query based on a where clause.

Lastly, I wrote the definition of the where clause in a self contained method. Again this is explaining the business logic in English.

In Conclusion, the project was a success. Although I wasn’t able to implement what I felt to be best practices, I was able to help myself learn the business processes quickly and more importantly help the next developer who works on the code base learn quickly as well.

More From My Blog