Web Skills

The Nettuts blog had a recent post about the skills required for web developers. This comes at an apt time for me. Our system might be going to the web sometime soon. The problem is that I am not a web developer. I am a client server developer. Usually that means you find another job. However I love the current project I am working on. I have been working on it for a long time. And I would like to continue this. Therefore it might be time to start shoring up my web development skill set.

The first item needed for good web developers is knowing a popular framework. Yes I have seen all the hype about Ruby on Rails. I dismissed most of it as hype. The only frameworks I know are those for client server development. However the hot new frameworks like Django seem to be web based. Maybe I will give them some time.

The next item required for web devs is knowing how to create widgets. That also seems like a good idea. I got a little excited when there was much hoopla over Google Gadgets. However I thought it more of a marketing ploy than anything else. You build a Gadget and get people to visit your web site. Maybe there is more to it than this.

Another web dev area is content management systems. Due to my blogging interest, I would not mind learning Wordpress or Moveable Type. Right now I just am a Blogger user. However the time may be right to understand more of what goes on behind the scenes. Our company is getting into social networking. The time may be right.

There are a lot of other web dev skills that were listed in the blog. The only other one that seems of interest to me would be ecommerce. It would be nice to know how to implement a payment system on a web site. For this I would probably go with the Paypal solution as they are very popular.

So far I have obtained approval to attend a Java class at the local community college. The company is going to pay for me. However I can see myself taking a Javascript class next. I like to have a college class drive me to learn these web development topics. It will also give me a good chance to network with other web devs.

Power of Metrics

The author of the Software Maintenance blog has found that metrics are not all they are cracked up to be. Yes in general metrics can be beneficial. But that presupposes that you use them correctly. The team should also know about the metrics process and understand how they are computed.

Sure you could conduct metrics gathering and analysis in secret. What good would that do? You could be sure that you have some objective handle on how a software project is progressing. However you want the metrics to work for you.

The trick is to be able to share the information on metrics without causing developers to game the system. For example, if you are tracking the number of days to complete a trouble ticket, developers could try to minimize this to the detriment of the project. Developers might only work on the easy problems. Or they could rush to close out other problems without truly resolving the problem. You definitely don't want to do this. But you do want the knowledge of metrics collection to spur developers on to good deeds. This is a tough balance to strike. Perhaps I shall post some more thought on this later.

Type Systems

Frequently I read debates over static versus dynamic typing. Even though I am a programmer, this is Greek to me. So I decided to read up a little bit on them. I also recently read a blog entry that made me want to get intelligent, or at least proficient in this area. Static and dynamic typing refers to two classifications of type systems. A type is best understood by developers through an example. Integer, float, and string are all examples of types. Now let’s get more into type systems.

There are a number of ways to classify type systems. One of the most common is static versus dynamic. With static typing, the type checks occur during code compilation. Examples of languages with static typing are C++ and Java. The idea is that you can catch errors earlier during the compile. Also, the stereotype is that programs of statically typed languages execute faster.

Dynamic typing delays type checking until run time. This is also referred to as late binding. Examples of languages with dynamic typing are Perl and Ruby. In general, dynamic typing is more flexible. You also usually have less code to write. However the drawback is that the result executes more slowly. You also spend more time testing for bugs.

A blog entry by Chris Smith says that strong and weak have no meaning with regard to type systems. Or to put it a little less bluntly, strong and weak can mean many things with respect to typing. Even the word type means different things in the systems. There is also overlap between strong and weak typing. Chris states that all languages inherently have some dynamic typing features. Chris does not buy into the stereotypes about the features of strong and weak typing systems.

Controversy aside, Chris has a lot to say about type systems. He explained that type inference means the compiler decides the types from source code without the need of explicit type declarations. Examples of type inference style languages are Haskell and C#. Chris does concede that static typing does have advantages such as better performance, documentation, and correctness. He makes some analogies for the two classifications. In static typing, a type is equivalent to a variable. However in dynamic typing, a type is equivalent to a value.

I have to confess. Even after boning up on type systems with some research, I had to concentrate to try to follow Chris Smith’s blog entry. Much more study is required in this area. I would like to at least get to the point where I could answer simple interview questions such as “Tell me the difference between strong and weak typing”.

What is an Operating System?

With the release of the new Chrome web browser by Google, some people are saying that it is the new operating system. Hanks Williams basically agreed in his “Why Does Everything Suck” blog. His opinion is that you do not need device drivers to be an operating system. The operating system is something that an application sits on. He reviewed the limited operating system support from the old days. I laughed when I read a comment on that blog that Microsoft says an operating system is whatever they sell.

This discussion brings up a good point. In essence, what constitutes an operating system? I think a good way to determine whether or not something is an operating system is to see whether it relies on some other software piece to run on the metal. For example, you might ask whether Windows XP is an operating system. If you take a personal computer, and put Windows XP on it, can applications run on top of it? I’d say the answer is yes. Therefore I would conclude that Windows XP is an operating system.

You could apply this analysis to Google Chrome. Suppose I take a personal computer. Could I then install Chrome on it and run applications on top of Chrome? The answer is no. Chrome does not run by itself on the raw personal computer hardware. Right now Chrome ships only a version that works on Windows. Chrome requires Windows to handle the network cards and the hard disk and the computer memory. Thus I would conclude that Chrome is not an operating system.

It is often easy to get confused by matters such as these. However the right viewpoint might clear things up. Yes I can see how Chrome might provide some services to web applications that run inside it. However that does not mean that we call Chrome an operating system. The point may not be important. But I think it is good to work on a common and clear definition of terms in the tech world.

Often I need to head to Wikipedia to explain terms that I need to define. So I looked up operating system. Now it was not decisive on what exactly constitutes the minimum requirements for an operating system. However Wikipedia did confirm that most operating systems have parts which are not part of Chrome such as networking, virtual memory, disk access, etc.

Language Requirements

This weekend I read a paper entitled “Ada, C, C++, and Java vs. The Steelman”. This paper was written by David Wheeler. The Steelman is the requirements document for the Ada programming language. The paper stated that Ada implemented 93% of the requirements from the Steelman. C++ on the other hand only implemented 68% of the requirements. You would think that Ada would rank higher since it was written to meet the language requirements. I thought I would list and comment on some of the requirements from the Steelman here.

Simplicity: One thing I know about the C++ language is that it is very powerful. However with that power comes a level of complexity. I do not think C++ can be considered simple by anybody. However that is not necessarily a bad thing.

Maintainability: On this topic I am divided. Since C++ is not a simple language, it may not be as easy to maintain in general. However the layout of the structure with the use of classes may make some maintenance tasks easier. C++ may get a grade of C for maintainability.

Efficiency: The C programming language has been know to be low level among the many high level languages. As such it is highly efficient. C++ adds a bit of complexity to C. That may incur some overhead. But I still think as a whole it is an efficient programming language.

Function vs. Procedure: In the C++ programming language, there does not seem to be any explicit difference between a function or procedure. In fact, all the C++ class methods would be considered functions. However I have written in other languages where a function returns a value, and a procedure does some work with potential side effects, but does not return 1 value.

Exceptions: I do know that C++ has exceptions built into the language. However I myself do not personally use them that much. I try to code logic for exceptional situations directly in my code without using the exception functionality.

Assertions: I believe the C++ assertion capability is a carry over from the C programming language. I do like the ability to use assertions. This is a positive programming feature that C++ implements.

There are a whole lot other requirements listed in the Steelman. Some of the more interesting ones are on the topics of tools, constants, indirect types, strong typing, recursion, and short circuit. C++ fares well in each of these. However it is time to wrap up this post. It is interesting that C++ caught on, but Ada did not seem to. That may be ancient history as C++ loses its popularity to a number of new languages available to programmers. I hope C++ remains immortal like C is.

Fate of COBOL

Today some of the cutting edge computer programming languages are Django, Drupal, and maybe Ruby. However just 5 years ago a study found that there were over 180 billion lines of COBOL code still in use. This can become a huge problem as the number of COBOL programmers is decreasing about 5% every year. Currently there are under 100,00 COBOL programmers out there. You can do the math and see that there will not be enough of them to maintain the current code base in a few years.

There are still some new core applications being written in the COBOL programming language. The problem is that it is usually more fun to be a Java developer. And it can pay better as well. So your top developers are probably not going to be COBOL developers any more. COBOL coding is not exactly rocket science. The COBOL language is meant to be easy to read.

I heard a funny joke the other day. Some developer got seriously sick. So they froze his body. When they thawed him out, there was a lot of commotion. Apparently they needed this guy back alive and kicking pronto. It was nearing the year 3000. And they were encountering all kinds of Y3K bugs. It seems the Y2K coders only did a patch job 1000 years in the past. LOL.

A number of sources have informally estimated that only 20% of development work is coding new apps. The remaining 80% of the work is maintenance programming. In addition to COBOL, there are other legacy languages out there like FORTAN, RPG, dBase, and Mumps. These languages probably have the same problem as COBOL. However there may not be as huge of an installed code base as there is with COBOL programs.

Perhaps I should join my buddy and become a COBOL consultant. Like I said before he makes a good deal of money. There is one problem with that plan. He has to travel all over the United States to get his gigs. And they hardly ever last long. They like when he comes in and solves their problems. He takes care of the issues nobody else likes or knows how to resolve. That kind of sounds like my job. I work in C++. If you ask some people, C++ is also losing its juice and will somebody be the next COBOL. I say bring it on.

Better Programming

The Geekaholic blog by Aditya Mukherjee contained an interesting blog post recently. The title of the post was “A Faster vs. Better Approach to Reach Your Programming Goal”. Aditya had a number of insights on how to program better. He declared that a module has to work within a program. The result should be a program which works as a unit. You should write code in such a way that, no matter how much code you add, the existing code will work.

Aditya goes on to recommend you ensure new developers will be able to work with your code. It would also be best if such a new developer could pick up any piece of your code and understand it without having to go through all of your other code. Here is a list of Aditya’s additional recommendations:

1. Make use of functions
2. Make use of Macros
3. Make use of procedures

This all comes at a great time for me. I am in the middle of coding the new changes in our software for next year. We have a mandated deadline for our code. I planned to attend a training class this month. So I got all my work done early. Another developed came forward and said he would not be done on time. These two facts resulted in me getting some more work.

Now I do not dislike more work, especially when it is software development. More specifically I love to code. However I have a one week to complete a task that was supposed to last a couple weeks. This is life in the software development world. I am not planning to work too many extra hours this week to cope with it. Instead I plan to change the way I work. I check in my code daily to ensure all code is integrated early. I also am coding the bare minimum required functionality first.

Here is the bad news. I may be taking some shortcuts in my coding to get the job done on time. That does not mean that I do not use functions or procedures. That would be plain evil. However I might hard code some values. And I might use the leanest methods to pass data around instead of creating classes or even structures. This is the price you pay when you get unreasonable demands and there are finite resources.

College Course Books

I used a web site to look up the books required for Computer Science courses at Stanford, Berkeley, and Princeton. Some of the titles were as expected. However there were some surprises as well. These are all respected colleges. And you would think that you could gather important information by analyzing their required college texts. I thought I would go over some of the book patterns I read about.

One thing that was apparent was that Java books outpaced all the rest by a factor of three. This is somewhat expected since recent college grads are the Java generation. You would not expect a huge emphasis on the C or even C++ programming language any more. Another no brainer was that Berkeley required a book on the BSD operating system. They are true to their own.

Stanford required a C++ text. Perhaps they are one of the last to continue teaching using this programming language. That is too bad. 10 to 15 years ago C++ was all the rage. Stanford also requires a Standard Template Library book. Being a C++ guy myself, my vote is for Standard. Finally Stanford stood out as the only of the three schools requiring a book on the Scheme programming language.

Berkeley seemed to have the longest list of required course texts. They had one course that required a book on graphics which seemed to stand out. It also required The Mythical Man Month which I would normally not expect to be presented in a college environment. This is a positive surprise. Berkeley was also the only school of the three that required a book on Design Patterns. It is surprising that more colleges do not require this to be taught. I was happy to see that Berkeley also required a book on Python.

Princeton had a couple surprising course textbooks. They required one on Artificial Intelligence. They also required a book on the ML programming language. That seemed a rare thing. There were also a number of required course books related to computer networking such as TCP/IP and UNIX. Those are all good things.

You can learn quite a bit about a college’s computer science program by studying their required course texts. If you want to learn some of the skills that top CS colleges teach, you could spend some time reading the books yourself. This is no substitute for a college degree. But it would make for interesting and useful reading nonetheless.

Chess AI

I read a most interesting blog post called “Chess Programs Are Not Smart” on zenpawn’s blog. This post was an attempt to generate discuss by providing a guest article written by Thomas Hall. I must confess that I used to play a lot of chess in the old days. Now that I am a software developer, chess programs are especially an interesting topic to me. First I plan to review what the author of the guest article stated. Then I will chime in with my own two cents on the subject.

Hall agrees that chess programs of today are indeed very successful. Two years ago one of them beat the human world champion at the time. However the problem of making a good chess program is difficult due to the number of possible moves in chess. No matter how great the hardware, the computer is not able to consider all future possibilities for any move. Therefore the computer must make some crucial decisions to arrive with a move in a timely fashion. The open and end game are especially difficult for a computer to analyze. Therefore most good chess programs rely on opening books and end game tables to determine their move. These techniques are wrote memorization and not any real insightful intelligence.

My own take mimics the initial statements by Hall. I would also add that the goal of good chess programs is to win. In that regard, they are most successful. Their goal is not to further the research of computer artificial intelligence in games. If that were the purpose, then I would imagine the programs would not be very good at winning. I am a coder. Zenpawn (the owner of the original blog) is also a software developer. My thought is that since we can code, we should ourselves write up some AI programs to get out computers to actually learn to be good at chess. I mean can’t we teach the computer the rules, let it play against itself for a long time, and make it learn?

Yes tasks like this are easier said than done. However it would prove fruitful in the sense that we would actually be trying to advance the world of computer artificial intelligence. The point here is that we should not look to commercial successful chess programs to do that. They are too busy beating the pants off grandmasters to bother with AI research. Cheers. And to close with a cheesy line, checkmate.

Creative Programming

Last night I read a blog post on LifeDev entitled “14 ways to learn from creative programmers”. I found there to be all kinds of good ideas on how to get more creative. In fact, I plan to take actions on some of these items right away. I want to go over some of the most interesting from this blog item’s list.

Number 1 is to learn a new language. I think I would like to tackle C#. Although I tried to learn it last year, it might be time to get into it deeper and code a significant app in it. For my job I may need to move to the Java platform. We shall see.

Number 4 is to do it for fun. This one I already do to some extent. I write code in my own time. Also at work I take part in some side projects. These are coding exercises that I do just because I like doing them. In addition, I usually share my results for free on the web. This benefits me as well as my audience of my blog where I release my apps.

Number 6 is to find a passion. Over the years I have actually started to really enjoy software maintenance. This is an easy field to get work in. Many developers hate debugging code and researching bugs. I find myself fully engaged in the matter frequently. I would actually call it a passion. My top blog is one that focuses on software maintenance.

Finally number 7 is master your tools. I have worked with Visual Studio C++ 6.0 for over ten years. It is an understatement to say I have mastered this tool. However that tool has almost become obsolete. So we started using Visual Studio 2005 at work. And I can get by. But it takes a while to figure out how to do things with this version of the IDE. Time to get busy, write a bunch of apps with it, and master the darn thing.

I encourage you to check out the LifeDev post yourself. This post has reviewed the four items that most applied to me. But the other ten may be more applicable to you. Good luck.

Cited Articles

I recently read a web article that ranked the top 200 articles cited in the area of computer science. The amazing part was that, for the majority of these articles, I had never heard of them. And I do not think that this is because I am not well read. Perhaps these are specialized academic articles. Or maybe the sources that reference them may be highly academic. However I would like to mention those seminal works that I did recognize.

The 6th most cited item was “Design Patterns: Elements of Reusable Object Oriented Software” by Gamma et al. Almost all developers know this work by the Gang of Four. I have a confession to make: I have never read this book. But that does not mean I don’t know enough about it already. The reason why I have not read it is that I think, after many years of software development, I know what an iterator is. I truly believe this book is one of the most cited works given the excitement over design patterns.

The 10th most cited work was “The art of computer programming, Vol. 3: sorting and searching” by Donald Knuth. Like the last one, I have never read this book. However I know developers who worship the work done by Knuth. A past coworker of mine first read the Design Patterns book. Then he said he started a long study of the Knuth book. You have to really work hard through the examples in the book to get the full benefit of it. Someday when I have free time I may do this myself.

Down to the 34th most cited work was “Object Oriented Modeling and Design” by James Rumbaugh. I am only familiar with this book because I surveyed the literature when I got into object oriented programming. The author is one of the big time guys that got together to produce the Unified Modeling Language (UML). So you know he must have good things to say. I am surprised his work was this high in the list. I expected a Grady Booch work to be up there higher than his.

Finally at number 131 is “Object-Oriented Software Engineering - A Use-case Driven Approach” by Ivar Jacobson. A while ago I was really into use cases. So even though I did not read this book, I knew about it. It is funny. I have not read any of these top cited works. But at least I know about a couple of these. What about you? Have you read these popular documents? If not, I encourage you as well as myself to do so real soon.

Haskell Paper

I read a blog entry by Matthew Sackman regarding a paper he co-wrote. It was entitled “Session Types in Haskell” and was submitted to Haskell Symposium 2008. The paper was not accepted for the symposium. Apparently the paper was reviewed by 3 different individuals. The decision to not accept the paper was made by these 3 people. Matthew’s post essentially challenged the comments he received from his reviewers.

I must confess that it seems like he was whining throughout his response to the feedback. Now I can understand that his paper may have taken a lot of work to produce. However I cannot understand what he was trying to achieve by crying over the spilled milk. He did come forward and say that he was initially must more upset about the decision on his paper. In this word of the web, why can’t you just publish your paper on the Internet?

If your work is truly revolutionary, you can just post your paper in your blog. Better yet you can publish it on your web site. Yes you will need to do a little marketing to get your idea out. Reddit or Digg can help with that. It will not carry the same weight as if it were presented at a conference. But so what? Another angle would be that you could improve it, or come out with a stronger paper next year. The best revenge is to triumph and become famous and rich.

Somehow I suspect that Linus Torvalds may have received some rough feedback the first time he put out his ideas for a new kernel. I bet he didn’t go running home to his mommy. Well, since he actually lived with his parents when he wrote the Linux kernel he may have gone home. But he would have locked himself in the room with his computer, written tight code, and owned the UNIX world. The sooner you get a good attitude, the sooner you will overcome a bad day.

Cheer up Matt. Before yesterday I had never heard about you. If your paper was accepted at Haskell Symposium 2008, I still may have never heard of you. Now I do know a little about you. And I don’t think highly of your post that whined. Your blog is hard to navigate too. But I am hoping you take this opportunity to come back with a vengeance and become famous. Then I can say that I wrote a blog entry about you when you were a nobody and were down on your luck. Mkay?

Array Versus List

Recently I coded a small utility to search my hard drive and clean out files built by Visual Studio. In essence it removed the contents of any Debug or Release sub folders anywhere. I needed this to be able to quickly copy just the source code of a number of projects for another developer. To do this I decided to queue up the directories to delete as the program found then during search. My top choices on how to hold the list of growing directories during search was either an array or a list.

My tool of choice for coding up quick utilities like this is Visual C++ version 6. And I normally employ the MFC classes because I am most familiar with them. So I had to make a choice between the CStringArray and CStringList classes. Usually I go with CStringList because I know the class member functions by heart. However I decided to determine my needs and use the class that fit those needs the best.

The algorithm was to make use of a queue. Every time I found a directory I wanted to add it to the beginning of the queue. And when the program was ready for more processing, it would take the element from the end of the queue. I decided to go with CStringList as usual. The AddHead() and RemoveTail() operations were just what I needed. RemoveTail() is especially useful because it gives me the element I want and removes it at the same time.

I will confess that performance did not even enter my mind when making a decision on the class to use. But in retrospect, the list may very well be the fastest choice anyway. It should be easier to remove items when all that connects them with the rest of the list are pointers. A brute force implementation of the array would not best well suited to insertions or deletions at one end of the array.

Software Patterns

Everybody has hopefully heard about software patterns as applied to software development. The "Gang of Four" are legendary in software circles. This is all fine and dandy when you are constructing new code. But do software patterns apply when you are fixing bugs in software maintenance mode?

I recall a time when we released some software into production too early. The result was a lot of trouble ticket, and a lot of trouble. It got to the point where we had to call an emergency meeting with the entire project to brainstorm ways to turn around the problems. One of the programmers stated that he read the famous software patterns book. And he wanted to apply some of that logic to our problem. He was politely but immediately turned down.

The idea of software patterns applied to bugs may not be a bad one. It all depends on your outlook on software maintenance in general. Is the goal to hack together a solution as quickly as possible to resolve the problem? Or is the goal to come up with the solution that best improves the system as well as resolve the bug? This second option will most likely take the most time locally. But it may provide the best overall return on investment. The problem is that this is a hard sell when users need a fix yesterday.

To apply software patterns to the bug arena, it might be best to refactor the problem resolution phase as follows. Determine what the actual problem is. Then with that insight, determine whether there is a way to redesign the broken part of the system using the simplest pattern to improve the code. This does not need to be done for the sake of using patterns. But it should be the first consideration in order to continually be improving the code base while performing the chore of correctly bugs. I am sure that I am not the first one to think about software patterns in this arena. However it might not be widely publicized as software maintenance is not a popular topic in the software community.

The Developer Experience

Software maintenance as a whole is often given a low status. You do not often hear that a company's top talent is assigned to maintenance tasks. Perhaps they need be.

It is no wonder why the best developers do not want to be assigned to maintenance. There are often poor working conditions. This applies both to the physical environment and resources you are provided. It might also apply to the technical personnel you must work with.

Like many other areas of software engineering, I have heard that the maintenance phase is more and more becoming an activity that can be outsourced. This is understandable given the low status of the activity.

However maintenance is not all doom and gloom. There are some fun aspects to working on the maintenance team. You normally can achieve quick closure on issues. Bugs can be researched and resolved within a week. Normal software development cycles are very long, with customers not seeing the end product for a year or more. Given a broken maintenance project, you can implement process improvement and hopefully see positive results from your efforts.

On a personal note, I myself have spent the latter part of my career in the software maintenance realm. There have been a lot of ups and downs. Luckily I am on an up cycle right now.

Lack of Information

Software maintenance as a field seems to be kept in the dark. Have you ever heard of a conference dedicated to maintenance? It is just not sexy or important enough.

There is also a general lack of books dedicated to the topic. Some books might mention the maintenance cycle in passing when discussing all parts of the software engineering life cycle. But we need details to survive the maintenance conundrum.

The problem extends into education. There is a lack of courses on this topic as well. The best that I remember from Computer Science was one on Software Engineering. However I gauge that most of the class got little information on maintenance from that class.

Finally, I do not think I have seen many web logs focusing on the software maintenance task. Again this may be due to the fact that developers don't like doing maintenance. I figure I can do my part by continuing to explore the subject in this and other blogs I am involved with.

Making the Best

Given the challenges of maintaining software, we can still make the best of the situation. Part of this can be set up during the initial software development. Designs with high cohesion and low couple make for easier maintenance later. But often this is out of the maintenance engineer's control.

A good problem resolution process can also go a long way to keeping maintenance tasks under control. This can be applied to any level of software maintenance maturity, because there is always room for process improvement.

The main way to ensure quality software maintenance is to drive it from a management level. This could be as simple as keeping an accurate work breakdown structure of major tasks. It will serve as a communication tool to internal staff as well as external customers.

Another beneficial management tactic is risk management. Being proactive instead of reactive to perceived risks is essential. And being proactive requires more than just lip service. It means truly analyzing, documenting, ranking, and mitigating risks before they become problems.

This is just an overview of ways to control the software maintenance beast. I plan to discuss each of these topics at length later.

The Good News

Luckily there are some troublesome parts of software maintenance that we can impact. Often times these mark the difference between success and failure.

In the heat of a broken system, there can be a strong desire to fix bugs ASAP. Often a conflicting goal is to make updates which keeping costs under control. It then becomes easy but detrimental to allocate limited resources to problem resolution.

Even though maintence is often a huge part of the software life cycle, it is not given priority. Lowly employess get assigned the bug fixing tasks. Original developers are usually not around once the system has been delivered.

And while maintenance usually comprises of fixing bugs, the system requirements can be ever changing if customers are not managed well. The good news is that this and all other issues I list here can be avoided or minimized with good management. This is the heart of what I want to dicuss and explore in this blog.

Out of Control

There are many challenges associated with software maintenance that we have no control over. It is good to identify these to know what we are up against.

There may be a significant existing code base. This can make it hard to comprehend the big picture of the system. The system may span multiple software products. To compound this problem, there is almost always insufficient documentation if any.

The design can be hard to follow. Sometimes good initial intentions deteriorate over time. This is inevitable when somebody puts a patch on top of the patch of the patch. In the end, you not only have something that is hard to maintain. It can be nearly impossible to understand.

Use of the system may require live data. It may also require lots of it. Typically the software works fine in a development environment. You often cannot replicate production problems. This can lead to a balancing act to keep up with problems but protect the live and often sensitive data.

Maintenance Characteristics

Previously I had tried to define software maintenance. This proved to be a challenging task. It might be easier to list some of the properties of the maintenance world.

Most software maintenance is not actually "maintenance". That is, much of the work is more than just preventative tasks to keep the software running. It is frequently described as the evolution of the software.

Software maintenance can be likened to a service. Often times it does not involve touching the code. It may just be an advanced form of user support. One thing is certain. The activity is very expensive in terms of the total cost. It can easily be well over 50% of the costs over the lifetime of the system.

The dark side of maintenance, like software development, is that it has a low success rate. Software maintenance can often spiral out of control. This is just the tip of the iceberg of nasty challenges performing maintenance. But this is a topic all its own.

Maintenance Definition

Before we start discussing the intricacies of maintenance, it would be good to try to define it as it relates to software. One might think this is simple. A user submits a report that a program is not working. However maintenance consists more than just fixing bugs.

Even when problems are being resolved, the changes reach farther than just the code. Documentation often needs to be updated. The original design may need to be updated. Test plans may need to be updated or even written.

Some environmental changes result in maintenance work as well. The data being processed may change. Or there may be additional features required in the software. A new operating system and/or compiler could drive maintenance tasks.

A change that could be classified as bug fixing is resolving performance problems. These problems could stem from larger amounts of data. Or there could be unusual combinations of data which do not scale well. To the user this is just another problem. But the work performed to fix this may be much different.

As you can see, software maintenance does not fit neatly inside a box.

Start it up

I fix software bugs for a living. That means I live the maintenance trenches getting dirty daily. But recently I have been thinking more profoundly. I focus less on the details of the latest software bug. And I ponder the theoretical side of fixing code.

It is easy to jot down the random events that occur during the work day. It is more work to recognize the patterns of software maintenance. A great artist once sang, "Stand in the place where you are. Think about direction. Wonder why you haven't before".

So let's do this. Let the deep thought on fixing bugs begin.