Bryan J. Holmes' Weblog

Comments in Code

2007-10-25T14:37:01Z

A trip down memory lane: Years ago, while attending the fine institution known as The Pennsylvania State University, I anxiously awaited a grade on my latest programming assignment. Pardon the pun, but I was trying to avoid another C on my C++ programming project. I had thought that the last program I turned in was completed perfectly, but I got knocked by the professor for not commenting my code. I thought it was nonsense. And then when I got my 2nd consecutive grade of a C –, I thought it was even more nonsensical. Why would I need to comment my code? My thoughts were that the professor was an expert in this field and that he and should know exactly what my code meant. … Now back to the present day.

]]> What a fool I was! (Note - I am sure that those who know me are probably taking a screen print of this right now to provide evidence of my admitting this fact.) I have come full circle since my college days, and thinking back, if I were that professor, I would give students an F for lack of comments.

Recently, I have been fortunate enough to be working with some historical code. How I wish that some of these developers had taken a class with my old professor! Why is it that our natural reaction is to not want to explain what it is we are coding? Do our brains start to only think in code while coding so that we can not translate our thoughts into friendly English text? Even when comments do exist, often the sentence structure is such that it appears that the developer was only allocated 20 words with which to explain themselves. Is there some misconception amongst programmers that if you can read prose, or actually write in prose, then you can not be a true programmer?

I’d like to change that notion. The problem is that, in many instances, comments are still added because the professor requires them, or the development guidelines require them to be there. They should be added to not just repeat what the code does in pseudo-code, but also to answer the question that can never be apparent – why is this code here and what is its purpose? I already know the answer that some programmers will give me when reading this – “that will make the code less clean.” I disagree with the notion that comments explaining the code dirty it up. Personally, I think it is cleaner when you can transition it to somebody years later and they can understand it.

Now excuse me while I go back and try and figure out what the heck I was thinking when writing this code from 2 years ago…

Soup To Nuts

2007-10-22T20:45:03Z

I have come to love this saying even though, until recently, the origin was never apparent to me. Regardless of the origin, the idea of taking something from start to finish is a wonderful idea. I have worked on a couple of different projects where I started very close to the beginning and ended my work on the project very close to the end. But why don’t all aspects of the project follow a beginning to end cycle?

]]> IT Projects technically are not complete until decommissioning; however, a main milestone is the initial delivery of the system. So for the purpose of this blog, I will refer to the delivery of the system as the final piece of the project. In order to go from Soup to Nuts during a project, one typically follows a system’s life cycle. Within a system there may exist a number of subsystems that also follow a life cycle. One example of a project within a project, that is near and dear to my heart, is the development of Reports within a LIMS project.

I have been involved in a number of report development projects and unfortunately, I see a lot of mistakes repeated throughout each project. We typically start out defining ALL of the reports for the project, as well as the process that we are going to follow in order to deliver a set number of reports (i.e. 20 reports) with the system. The process then goes something like this:

1) Define Requirements for 20 reports
2) Design all 20 reports
3) Develop all 20 reports
4) Write Test Scripts to test all 20 reports
5) Code review all 20 reports
6) Execute test scripts for all 20 reports
7) Deliver 20 reports to users

If only it were that easy. Typically, there are a number of iterations and changes that come up along the way. These issues also have a tendency to occur at a new process point. For example, when development starts on the 1st report a flaw in the design process is uncovered. This results in moving all 20 reports back to the drawing board. Then when test execution begins, guess what: an issue that was not thought of during the creation of the test scripts is uncovered. And the result, back to the drawing board for all 20 reports. Again.

One thought that I have been trying to perfect is the idea of taking individual reports from Soup to Nuts. Rather than work on 20 reports simultaneously, waiting until the 20th is complete to move to the next stage, why not start off by taking 1 report all the way through the process and verifying an entire report lifecycle. This does not prevent work from commencing on other reports, but it does require the Project Manager to be flexible. The PM has to be able to adjust and reassign resources on the fly in order to complete each report cycle when a report is ready to be moved to the next stage in the process.

The thought of switching resources around on the fly, and not having exact timelines, can be a problem for those who live and die by a Microsoft Project schedule and deadlines. In this world of LIMS reports though, I believe the flexibility will provide a much greater chance of success in the end.

Data Migration

2007-02-27T21:46:16Z

As the IT industry matures, companies are starting to realize the benefits of having a standardized approach to IT. This includes the use of common applications within a business sector. These applications can be a new application entirely for the company or an upgrade of one of a number of existing products in place. When a company decides to go down the path of standardization there are a number of things that need to be considered. One of the most important issues that a company needs to consider is the question of what to do with legacy data. Depending on the type of application, legacy data may or may not be required. In the LIMS world, foreseeable situations exist where the answer to the legacy data question is both! The question is then – migrate the data to the new system or warehouse the data? I will explain some of the considerations that should come into play when making this decision.

]]> There are a number of different types of data and it is very important to identify this prior to deciding your migration approach. Here are a list of questions you should ask when determining your approach:

1.) Is your data active and required to be easily accessible/updated/etc?
2.) Is your data only required for reporting purposes? Thus, no more updates to the data is required.
3.) What are the legal requirements for how long your data needs to be maintained? 5 years, 11 years, 20 years, etc?
4.) If data is active, how much longer is it active? When can this set of data be retired to the point that it is only required for reporting purposes?

These seem like obvious questions and they are. It always helps me, even though I know the questions I should be asking on a particular topic, to ask them – in order to better analyze the situation.

In the LIMS world, and other worlds, a plethora of applications exist. While the concept of what a LIMS must be able to accomplish is consistent across the industry, every application is different. Again, statement of the obvious – however, it is an important point to note. Different applications would not exist if there was not an underlying functional difference between them. Each company that develops a LIMS, attempts to create an application that can be applied to different categories of testing while maintaining some flexibility to allow for configuration and alterations of system setup. The benefit for the software developers is that they can penetrate new industries. The benefit for the consumer is that they can most likely make the system fit their business. The drawback for the consumer is that the application is not specifically designed for their business and options can at times lead to great complications. It also means that it can be very difficult to match systems of yesterday to these newer applications of today.

Data migration is a costly and time consuming process. It is difficult to map multiple existing systems into a new system that already has a predefined structure. Data warehousing can allow you the option to design your own data structure that can more easily accommodate the variety in data that you are retrieving. At the same time, data warehousing allows you to verify that the data is stored in a manner that matches your business – not just the flexible data structures that are created so that software can be used in multiple industries. Consider your data requirements and develop a long term data strategy. If you are looking to solely be able to report on the data, why not consider putting it into a warehousing structure that is designed for reporting rather than performing transactions?

Useless Information - or is it?

2005-11-16T14:38:52Z

Have you ever had that friend who always comes up with what is seemingly ‘Useless Information?’ If however, this information came up in a topic of conversation and it had some use or value, it would therefore render the useless argument - well useless. My main problem with people who categorize this information or any other information as useless, is the fact that they are only taking the data at face value. Where am I going with this you might ask? And if you aren’t asking that - you may be asking how this could be applicable to what we do at J&R?

]]> There is an old adage about turning data into information and finally turning that information into knowledge. The whole starting point behind that adage is based around taking what could seemingly be useless information to some, and turning that information into some sort of advantage for another.

An example I will use throughout this post is LIMS data, as this data is mostly regarded as transactional data rather than anything that can provide strategic advantages. LIMS applications are classified as OLTP - which facilitates data entry and data retrieval. The key component missing in OLTP systems is data analysis or reporting of data.

These data structures are designed in a format to provide the fastest mechanism for single record entry and single record retrieval. The databases are not setup in a fashion that would allow for more complex analysis to be performed in a simple manner.
This is where the idea of housing transactional data in a data warehouse comes into play. The new structure of the data provides new meaning to the data and turns it into information. What used to be a set of results that were either in or out of specification, is now turned into a trend of information that could include variations of the raw material providers, analysts performing tests, the time in relevance to the analysts shift that the tests were performed, instruments that were used for the tests, etc. All of a sudden this seemingly useless data could have shown you that when tests of Methyl-Ethyl-Ketone are provided by ABC Company and tested by Joe Analyst while working on the 3rd shift, the tests fail at a 70% rate. Now we are able to reduce the costs associated with testing by no longer having Joe test this product as he has an accuracy rating of 100% on all other products that he tests on 3rd shift.

This is a basic concept of data warehousing and data mining and you will see be seeing a series of blogs in the upcoming months in which I will discuss the benefits that can be achieved by having a separate environment that is designed for reporting purposes.

The Art of Planning

2005-09-20T14:12:59Z

Today’s society is one focused on results. People need to see results and see them fast. If the final result will take a while to become visible, progress must still be shown. We must have it and must have it now. Well, this attitude probably ends up costing corporations and people an extraordinary amount of time. The instant gratification needs of our society have resulted in a lost art: The Art of Planning.

]]> Have you ever pictured someone writing code or drafting a blueprint for their next building project? You probably think of this person either typing away at his/her keyboard or meticulously drawing away at their next masterpiece. Sure it gets to a point where these skilled craftsmen are able to actually work like this, but before this “real” work can happen a plan of action must be developed.

In an office setting, I have sat at my desk with my feet up portraying the appearance of staring into space. My boss would walk by and kind of give me a look along the lines of ‘what the heck are you doing?’ He would find it especially interesting that I didn’t jump up and pretend to go to work on my computer when he came by. Why is that – because I was sitting there thinking. I was running through a number of scenarios in my head, taking notes when needed, but thinking about a plan of attack on how to tackle the next assignment. The same thing can be applied to any aspect of life. Think of the last vacation you went on. Did you start to pack right away and then pack way too much or forget a number of things? Did you make a list of items that you needed to bring and then pack? Was this list generic (i.e. 5 pairs of pants, 5 shirts, toiletries) or more specific (1 pair of khakis, 1 pair of Levis Jeans, 1 pair of Dockers Black trousers, etc.)? Or were you one to go up, pull out the suitcase and go through drawer by drawer and figure it out on the spot?

The classic example of planning versus execution deals with the NFL. Each week coaches and players alike will spend upwards of 100 hours to set a game plan in place for their upcoming match-up. The total execution time is 60 minutes or 1 hour. They plan out just about every scenario. Even though every team has 3 Quarterbacks on their roster and the odds of having each one of them hurt in the same game is very slim, each team has an emergency quarterback who is a position player who may have played quarterback as far back as high school. I wouldn’t be surprised if each team also had a 2nd backup.

The NFL is the standard as far as planning goes. In the real world, unfortunately we are not able to anticipate or prepare for issues as easily as in the NFL. This doesn’t mean it is impossible, but rather that it just takes more time upfront. The problem is that most project plans are created very early on in the project with little time spent on creating the actual plan. This allows for more time to be spent on each deliverable in the plan. Think about it – the project plan for a project that could have costs of $1 million or more, with a timeline of over a year was crafted in a week. Maybe 2 weeks. Heck, I’ll even give you 3 weeks. After those 3 weeks, the boss wanted to start seeing results as the 1 year deadline was looming. Well, the result could end up being a project that wasn’t planned properly, went over budget or any of a number of other things that could go wrong.

Next time you are looking to get a project going or are looking for immediate results for a newly commissioned project, think about things a little differently. Act as if it is a game plan and not a project plan. One that you want to see executed to perfection, not one that ‘will have to be tweaked over time’. And remember, individuals may plan best via different planning techniques. Just because sitting with my feet up looking as though I am daydreaming works for me, doesn’t mean this will work for you (or with your boss!).