Joel Hainley

One of the things that you notice if you are around development/engineering teams enough is that there is normally the existing solution, and the “next iteration”. Much has been written about the “second system” phenomenon and all of the pitfalls and failures that have resulted by second system thinking. Today I just want to talk about the importance of maintenance work to the growth of a developer towards understanding the hard problems within their chosen problem domain.

It seems like maintenance programming is, according to some developers, the lowest form of development on the planet. If you’ve ever been on a team in the role of maintenance programmer you have probably noticed that it’s not considered “sexy” by most of the team. Everyone is glad that you’re the designated maintenance programmer because that means that they AREN’T. Everyone wants to be working on the second system where “things are cleaner”, “we’re using better technology”, etc.

I’ve never agreed with this mentality, and here’s a dirty little secret, I LIKE maintenance work. There are few things as challenging as debugging a problem in a system you haven’t designed and fixing the problem in such a way that you leave the code better than it was when you got there. Here’s another amazing benefit of maintenance development, you learn the system and you learn how other people think and approach problems. In a similar way that Rorschach and Perceptive Aptitude Tests work, code is a projective tests for the thought processes of the developer who wrote the code. The other amazing benefit of supporting an existing application is that within a VERY SHORT amount of time supporting an existing application, a new developer is going to learn the system backwards and forwards. The developer will end up having a very deep understanding of the problems inherent in the existing design from a very realistic standpoint.

See new development is easy, you’re just trying to hit the 80% mark. If you’re in development you know what I’m referring to. “80% of the functionality is solved by 20% of the work.”. I’m willing to argue that the real work involved in a new application is done after the application is in production, that’s when you start to work on the last 20% of the application.

Maintenance work ( debugging production problems, adding new features, etc ) is when you start to solve the really hard problems that were not seen, or deferred, by the team creating the application. You often have to be creative in how you quantify the problems you are seeing, and you have to be a bit of an artist in terms of how best to quickly and easily ascertain what the hell is going on. The great part though is that you start to see how the choices made during the implementation of the system impact your ability to respond to certain things. This is the reason that I think solution architects should be in the trenches writing code with everyone else. They need to understand the results of their decisions at a very fundamental level, and the only way to do that is to keep their head in the game.

The other great thing about doing maintenance development is how easy it is to measure your contributions to the team. It normally goes like this, Tuesday morning the big client calls, he has found a bug that needs to be resolved by Friday or else they are going to have to leave the team. Tuesday, just before lunch, a meeting is called, and bad pizza is ordered. You are brought into the meeting and asked how in the world this can be fixed before Friday. If you just built the application but haven’t spent time doing maintenance since it’s release, you’re going to have to look into the application and reacquaint yourself with how it works, and see what new things have been added since you last saw the code. However, if you’ve been doing the maintenance work you can speak with authority right there in that meeting about what it is going to take to deal with that issue, and with any luck it’s already something that you have thought needed to be dealt with and have an idea about the best approach to take. So you grab two extra cokes and the last box of pizza and go back to your desk and solve the problem, test it, get it through qa and into production. A specific measurable result for your efforts, and something that others will remember.

Obviously I love to do maintenance work, I am VERY often called by clients to deal with legacy situations. I can’t count the number of times that I have had a client call up and tell me that the only person who knows anything about the application has left and “they have a huge bug and he’s trying to charge them $400 / hr to deal with it”, or they “have fired their consultant and are now left with a huge mess on their hands and could you help us”. I love this work, it’s real, it’s necessary and it’s often challenging and interesting. If you need maintenance work done feel free to contact me, I’m always looking for chances to sharpen my debugging, and code-reading skills.

There’s no doubt that today web services are hot, all of the commercial platforms ( J2EE, .Net, etc ) have tools that make the development of web services very easy. There are also a bunch of tools that are out there that help people generate their WSDL’s and can generally ease all of the difficult parts of developing web services. The great thing is that with the release of PHP 5 we now have tools that allow us to quickly develop web services in PHP. The great thing about this is that you can stub out api’s and start to have different solutions speak easily among themselves, share business logic to languages and technologies that are “not native”.

Within this article I’m just going to hit some highlights about creating your own web services using SOAP and PHP. I will also provide a URL to a web service that I have written for people to fiddle around with their first SOAP client. Please note that I’m not providing an exhaustive example of all of the details of wsdl’s/SOAP and the like, this is the SOAP equivalent of a “hello world” program, but with parameter passing included since most “Hello Worlds” don’t have parameters passed into them. We’re going to be building a little service that will support 2 operations, rot13 of a supplied string, and the mirroring(reversing) of a supplied string. Nothing terribly fancy, but certainly more interesting than “hello world” .

You can see the WSDL for this service here . There isn’t much to note with the WSDL it is a simple service and I’m not trying to get too crazy here. So take a look at it and see if it makes sense, if not, try to compare it against the code samples below and see if you can determine how it all relates.

Now that we have the WSDL defined it’s time to build the SOAP server to support this WSDL. Here’s the full listing for the server :

Pretty easy to understand, you’ll notice that we are just defining the functions at the top, then once we have created the soap server using the WSDL we simply associate our php functions with the functions defined in the WSDL by passing the function name to the addFunction message of the newly created SOAP server. Note that we have turned off the caching of the WSDL, this is something you’ll wanna do while you’re developing. When you don’t do this and make changes to your WSDL and they never seem to take, it can get frustrating .

Ok with the server out of the way let’s turn our attention to the client. Here’s the listing for a simple client :

I’m sure you could write a fancier example, but it gets the point across. First, You turn off the WSDL caching on your client as well as the server. Then you create a new soap client using the wsdl. Then you just start calling methods that you defined in the server. That’s about all there is to it.

Note, I’m going to keep the Soap Server referenced in this article up for you all to use. Please feel free to use it for testing your clients as you’re getting up and running. Eventually you’ll wanna start using your own servers for more interesting things though