BKeeney Briefs from 7.3 (March/April 2009)

As a consultant I have a lot of projects come my way. Most projects I'll take but sometimes I'll pass a project up for one very simple and very important reason: OPC, or Other People's Code. I supposed I should explain a bit. OPC isn't necessarily a bad thing. REALbasic makes it easy for beginners and hobbyists to create decent applications with a minimal amount of effort in a short amount of time. However, it doesn't mean that they've used good design and programming principles. People bring their projects to me (or any other RB consultant for that matter) because they don't have the time, inclination, or ability to do it themselves. Generally this results in the client having some good ideas on how the application should work since they've done some design work. There are some clients, however, that are coming to me because they have a working application and need it to do something different, better, or it crashes too often, and they have no clue how to do it. These are the worst projects to take on, from my experience, for several reasons. The first is that no matter how good of a programmer they are, you'll spend a lot of time just figuring out what they've done. Again, RB makes this easier than some other languages but you're expected to learn something intimately and do it quickly so as not to waste the client's time and money. Secondly, if they don't have any programming experience you'll be fighting their code from the beginning. One project I looked at had a huge number of global objects including a recordset that was used everywhere. I suspect that the application had data corruption issues. The application also had no error handling whatsoever and had hard coded paths which only worked on pre-2008 R3 builds. Just to get it to compile to start working with it was a day's worth of work (minimum). Thirdly, clients that bring OPC projects expect the work to be done quickly and cheaply because they've, "already done the work." The two big warning signs I look for in these projects are clients saying that it "should be easy" and it "won't take any time at all." If that was true, they could probably have done it themselves. If a client throws their hands up in the air in desperation, it's a good sign they've realized they need experienced help. The last thing about OPC projects that I've found is that they almost always have no documentation. If they have a database, they have no explanations anywhere of what the fields are or what the table relationships are. OPC projects also tend to use very short, very cryptic variable names like i and x everywhere and they never have reasonably named controls. You know you're in trouble when you have a window full of editfields that are named EditField1 through EditField20 or maybe even worse EditField11111 if they simply duplicated their controls! Dealing with OPC projects requires a good deal of patience. You'll end up modifying variables and control names a lot simply to understand what's going on. Hang in there! The positive side of OPC projects is that your client will hopefully appreciate what you've done to teach them a few things. That is ultimately what OPC projects are for me: a way to teach the client how to code better in REALbasic. Happy Coding! If you have any comments, please add them on to the BKeeney Brief's blog at www.bkeeneybriefs.com.

Special Print Closeout!

OPC

Working with Other People's Code