Wednesday, September 29, 2004

How to Design Programs

(and more on QA and Testing)

Program design. This was the topic of my very first computer science class. We were writing in a language called scheme, which is related to LisP so I am told, the language wasn’t terribly important, but the concepts were. My professor, and the authors of the book that we used that semester were obsessive about the method by which one approached programming. All of the exercises in the class were aimed at helping the student understand why program design is important.

What struck many of us, as a new experience was that the actual coding of a program or algorithm was really a very small part of a larger process in bringing about a program; we learned very quickly that there were several steps that would help assure us as programmers that our program would pass the test of time.

In a nutshell we followed a pattern:

1 – purpose
2 – data analysis and design
3 – examples
4 – well formatted code
5 – testing (using the examples created before programming)

Looks simple doesn’t it? In theory it really is. However, when a programmer gets in a hurry, it is often very tempting to skip right to step three and write the program. This is one place where one quickly notices the differences between educational theory, and practiced reality.

The company that I work for has a huge IT department. Millions of dollars are spent on software development, as most of what we use has been home grown now for at least the last 30 years. I am a member Quality Assurance team that develops financial software for the corporation. Some of the code that I test has been around since the early 1980’s. Granted, in that day and age there weren’t great source management systems, and you usually needed to write your own, but you can easily tell that in many instances the above formula was not used.

I sometimes wonder if programmers who know that they have a QA tester to will just compile the code that they wrote and call it good. Yes, the bugs that I find have been that bad. Had the programmer actually run the program, he/she would have seen the errors nearly immediately. Yet at the same time, I can empathize with a programmer trying to maintain code that has been maintained for multiple years without documentation. It really takes time thinking and research to plow through code that you didn’t write before you make a change. There are a couple of programmers here that are very careful to understand before they go, but there are others that just edit, compile, and hope that it will work. I could probably go on for ages about why this style of programming is problematic, but the short answer seems to be that the problem is propagated by not following a plan.

In the world of object oriented programming, the emphasis is on creating code that can be used and inherited, abstraction is the name of the game. One would hope that with more complex source management systems, more powerful programming languages, and programmers that care about their code that more thought would go into design and implementation planning. OOP certainly encourages a programmer to think in this manner, but does it actually happen?

So for the motivation behind my rambling today; while sitting in our weekly status meeting with financial business owners someone says: “What if we were to plan and design each program request before we sent it on to be programmed?” What a novel idea. Certainly there would be some return on investment there, don’t you think? After the question had been asked, my co-workers began to discuss the pros and cons of program design, and in my head I answered YES.

No comments: