Pale Musings

Software engineers normally have a strong desire to produce code that not only performs the functions that are necessary, but to have the code be as elegant as we know how to make it.  In breif, we like to write nice code.  We want to follow patterns, promote reuse and extensibility and more.

The advantages of writing code in this manner normally manifest itself in value for the developer.  Rarely the value of these practices are evident in any way to the end user or to the person utlimately paying for the code in a way that is tangible to them.  There are benefits of course.  Adding a new piece of functionality later may not take as much time.  Tracking down a bug will normally be easier.   They just are not out in the open at the time of development.

It  is possible to go too far however.  As the architects and implementers of the architecture, we have to constantly monitor the cost/benefit ratio of the way we are writing our code.  We have to determine where the line is.  Not an easy task!  Knowing that every project we work on has a different line, if you will, makes our job of Hall Monitor more difficult.

I’ve been working on and off on a project that has had a very large scope.  It is a Windows Forms based application that pushes the envelope in the UI and I think it will ultimately be an application that is very easy for users to feel comfortable in.  The application will be around for a long time performing mission critical functions for the end users.  It is anticipated that many new features will be added and that some customers will have needs beyond the typical requiring custom “modules.”  We have worked hard to produce an architecture that is extensible and we’ve worked hard to build a maintainable system.  I suppose in some areas we’ve failed a little, but in most I believe that we have accomplished our goals.

We have another customer with a project that has some similarities in the respect that the final product will need to be extensible, probably be around for a while performing mission critical functions and need to be maintainable.  It sounds like fun and we will be taking many lessons learned from the previously mentioned application to make the architecture more robust.  This is a project that is just beginning to move from the design phase into development.

To throw that wrench in the works I spoke of earlier, a request came through from the second customer this week for a demo product.  Not just a static walk through of a few screens, but a little bit of functionality that the sales and marketing folks can take into the field.  This is a great idea of course, however the requirements for the demo are much different.  First, time is very important.  As most demos, it needs to be done quickly.  Second, budget is paramount for the demo.  If it is too expensive it is not worth it.   Now we see that there is a new line!

In producing the demo we have had to change our way of thinking from what is best for the long run to what is best for now.  We have had to realize that, while we may have a few gems of code in this demo, much of it will likely not be used in the end product.  Shortcuts for displaying data (using actual data binding…yuk) instead of more robust methods.  Forget the time to produce a nice data provider, just read from an XML file and do it quickly.

The customer understands that this is what they are asking for and realizes that there will be some work that is not used in the future, and they are fine with it.  As a software engineer and architect, it is our job to become comfortable with that as well.  I’m not suggesting sloppy code, no documentation or any of that, but I know that, for me at least, when I look at a function and realize that I could refactor it to be reused or to be simpler to debug, maybe I should not.  I need to move out of my normal mode of operation for a project like this.

Realizing that has also made me start to question on the other types of projects, the “gold code” if you will, if my lines are in the right spot.  Are there times when a class is just fine, or was the refactoring I just did necessary?  Now I need to look at it from the other viewpoint, do I really need to use this methedology for a component, or is it fine the way it is?

Food for thought if nothing else.  Let me know how you determine where the line is!