RiskFactor

A good friend of mine, Chris Deweese, announced this week that he is taking over a new responsibility at our company.  He will be the lead architect for a small team that will begin the process of migrating our current business off of the Mainframe over to a Windows based infrastructure.  This is exciting for me because I currently sit in the next cube over and we often talk about architecture and design issues, so I hope to glean much from him as he embarks on this endeavor.

Congratulations, Chris!!!

Tags: general

I have a friend who recently took over as Project Lead on a relatively new application at his work.  There are some changes in that application that he needs to make.  The changes range from the smallest portions of the application to some large architectural changes that need to be addressed.  As he has discussed it with others they tend to agree that the changes would be nice, but since they don’t directly meet a Business Requirement or provide new functionality and since the system already works, they will have to wait, “After all, you can’t stop a moving train.”

Software Locomotion

How many times have you heard that phrase when discussing needed changes to an application?  (Maybe since your a “Software Engineer” someone assumed that software development is like driving a locomotive.) Now, to be fair, one must consider the return-on-investment for any given change to a system. While this is necessary, we cannot afford to let ourselves settle into a paradigm which views software development as akin to the railway. In that paradigm we set our application on the two iron rails of Fast Delivery and Increased Functionality and throw the throttle wide open hoping that those two tracks will lead our application to increased market share and high profit margins.

However, one must also realize that as software ages, or becomes more “mature”, it also increases in complexity as a result of the continual integration of new functionality.  This is almost always accompanied by a degradation of the internal structure of an application.  Components that once where well partitioned and had clearly defined responsibilities now become bloated and start taking on responsibilities and unrelated functions like a sinking ship takes on water.  All of the sudden a seemingly simple change now takes an unbelievably large amount of effort.

At some point the reality that change must be made to an application becomes undeniable to anyone that takes a moment to evaluate the effort exerted for each incremental improvement.  This begs the question of why an application must become so complex before someone says, “Hey, I think we need to refactor this thing.”

Refactoring is a buzz word that is floated frequently in software development circles.  Is it really understood though?  Chances are that if you get a room full of developers together your going to have a significant number of differing opinions on what constitutes refactoring.  Luckily, Martin Fowler has written a great book entitled Refactoring: Improving the Design of Existing Code.  Fowler lays out a simple definition of refactoring in the preface.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs.

Even though refactoring is a straight forward concept it is one that many developer have a hard time implementing.  I honestly believe that it has to do with the paradigm that we as developers use in approaching our development.  We are often convinced of the “can’t stop a moving train” argument.  Well, what we need to do is approach our development and the changing of our application from a totally different mindset.

The Secrets in the Sauce

My wife and I spend a good portion of our television watching on the Food channel.  It just so happened that during an interview with one of the many Food Channel stars that they were discussing what makes a good chief.  One of the points made was that a good chief is should taste the food being prepared to see if it needs something more.  If the chief finds that it does not taste like they think it should then they add the necessary ingredient to change it.  They don’t do this just once, they are constantly doing in.  Constant tasting and making the necessary changes when needed and not waiting till the food is completely prepared before going in and making a lot of big changes post-facto, that would be absurd.  (I personally have this mental picture of a chief, who after baking a bake, realizes they left the salt out so they just grab the salt shaker and add it right on top of the icing.)

I would contend that just like a good chief, we as software developers must view refactoring in the same way that a good chief views taste testing.  Refactoring is an intrinsic part of what we do.  It’s not something that is left for a maintenance build.  It’s not a nice-to-have, but rather every time we open the code to add new features and functionality or fix a bug, we should ask ourselves how we can change the current code so that it improves the internal structure and cleans things up while adding the needed benefits to our end users. Part of the job of a Programmer is to continually be looking for ways to improve or restore the architecture and design of the system.  It is incumbent on developers to be active participants in refactoring the system they are developing because that is a natural part of what it means to be a developer.

Tags: architecture, best practices, refactoring

Where I work we have a number of applications that started out in VB6 and were ported to VB.NET.  I can understand why those have the spaghetti code that they do, but then there are those application that were .NET from the start and still have such tight coupling, lack of cohesion, and lack of encapsulation that it baffles me.  Since the advent of .NET the general discussion about Object Oriented software has migrated into the Business Application Developer sphere in a big way, but it seems that many developers have a hard time wrapping their minds around what that means.

Last week I had a set of conversations with some fellow developers about why some developers have a hard time thinking in OO.  The conclusion I arrived at was not that the concept of OOP is so difficult, but that it is such a different mindset from what I call a linear mindset that people struggle to re-orient the well worn thought patterns they have developed.  From my perspective the difference is between that of a linear thought process and a relational (or Object Oriented Thinking) thought process.

Many developers have a very fixed view of what they are trying to accomplish with their application (CRUD) and that drives there development.  They want to create some data, retrieve it, update it. or delete it.  This is a very linear type of process.  In essence the developer is thinking more in terms of the workflow of the technology for doing CRUD operations than they are the relational aspects of the real world objects and inadvertently strap themselves into an application design that restricts their flexibility.

What a developer needs to train themselves to do is to create software that mimics the real world objects and then compose those objects into the workflows they need.  This allows the developer to change the workflow without breaking the objects or change the objects without breaking the workflow.  When we throw in concepts like interfaces and base classes it allows us to think not only relationally but also more abstractly about the categories of objects we have and how those larger categories interact and fit into the workflow.

So what does this mindset look like?  Here’s an example.

You have a pizza you need delivered.  From a linear perspective you can code a method that takes a delivery id and gets a pizza row back from the database, you create the pizza object, walk out the door, get a car from the database, find the keys, start the car, get directions to the house from the database, drive to the location, take the payment and save it to the database, return to the pizzeria.  Or, you can create a delivery person object that accepts a pizza from the pizzeria (It’s the Pizzeria’s responsibility to compose the Pizza object).  He can use a type of Vehicle to travel to a location (It’s the Parking Lots responsibility to hold the car object).  Whether it’s an automobile or a motorcycle doesn’t matter, because the Delivery Person can participate in the transportation relationship with the Vehicle.  He then interacts with a Customer object from which he knows how to receive payment. (He doesn’t have to save the payment to the database because that’s the responsibility of the Cashier). If we abstract the Delivery Person into an Employee that knows how to receive payment then we can inherit from that common Employee class and both our Delivery Person and the Cashier in the pizzeria can participate in the transactional relationship with customers though the Cashier object will be the only one that can put the money into the cash register (think store the money in the database).

This is surely a simplistic example and is not meant to be fool proof, but I think it adequately illustrates the difference between the two thought processes.  Where as the linear thought process is more geared toward CRUD operations the Object Oriented approach allows for CRUD and also allows us to compose our objects into more complex workflows without having our business object and data access embedded in our UI.  What we should be striving for in OOP is to develop a deeper and more thorough thought pattern of seeing software as a set of real world objects that participate in relationships with each other.  We then utilize those objects to create our workflows and perform our CRUD operations.

One point I have to make clear is that I am not advocating that Object Oriented Thinking excludes linear thinking.  Rather, Object Oriented Thinking contains linear thinking but is not limited to it.  We have to use linear thinking to help us define the workflow branches, but we cannot allow that linear thinking to dictate the structure of our software.  We must force ourselves to look for relationships between objects and then to use those objects as the components our workflow will act against and utilize to fulfill the business requirements of our customers.

Tags: object oriented, oop