You are currently on IBM Systems Media’s archival website. Click here to view our new website.

IBM i > DEVELOPER > GENERAL

Methodologist or Gunslinger

Methodologist or Gunslinger—The Joel Test

Let’s look at each one. While all can (and perhaps should) be used by i shops, I think the first few are the ones most commonly not implemented.

Step 1: Do you use source control?

Several source control management (SCM) packages exist for i development. Some of the leading packages are MKS Implementer, Aldon Lifecycle Management, Softlanding Turnover and Rational products from IBM. Source control is always important for keeping track of changes to source code, but it’s absolutely critical when working in an ILE environment. Establishing procedures for checking code in and out, and managing programs, modules, service programs and procedures can be daunting tasks without automation. However, many (most?) i development shops don’t embrace ILE. I’m curious to know if shops that embrace ILE don’t use SCM, and conversely, shops that don’t use ILE that do use SCM. Why do you use or don’t use a SCM package?

Step 2: Can you make a build in one step?

The ability to build a software package (or system) in one step is less important for a shop with ongoing development than it is for a vendor that has to ship code to customers. For the i software vendors out there, is this an important consideration for you?

Step 3: Do you make daily builds?

See Step 2. This may be an important step for software vendors, but not for most in-house development projects.

Step 4: Do you have a bug database?

I think this is a critical part of the process. Keeping track of bugs that are uncovered during testing (programmer unit testing, testers testing, user testing) means that the bugs that are uncovered will be addressed. Too easily forgotten, a small bug discovered early in the development process can be a nightmare once more code is developed. Additionally, trying to keep track of bugs when multiple developers are working on the same project is almost impossible unless some type of database or repository is being used. Do you keep track of bugs found during development and testing?

Step 5: Do you fix bugs before writing new code?

You’re probably thinking “of course I fix bugs before writing new code” and I’m sure you do fix the easy ones. As Joel mentioned, a syntax error is found and fixed almost immediately. But other bugs, especially the ones that are known but glossed over, can be a project nightmare. Thinking that you’ll come back and fix bugs later can lead to code being written that uses the bad results as a foundation for new code. Trying to remember the bugs and the placeholders and the to-do lists and develop good new code is too much for most programmers. Take the time to squash the bugs before you move on—it will save time down the road. Do you fix bugs before writing new code, or do you continue to develop and use the best of intentions to come back and fix the code later?

Step 6: Do you have an up-to-date schedule?

As the saying goes, “I love deadlines. I like the whooshing sound they make as they fly by.” Schedules are important—they keep people on track and focused, they allow IT to communicate responsibly with the user community, and they enable other team members to coordinate their work. I’ve worked on (too) many projects where the schedule was set before the project was even designed. The idea that a schedule could be made and adhered to before the scope of the project was even known is one of the hallmarks of bad management. I realize that business needs require schedules to be made, promulgated and implemented, but they also must be realistic. Do you have a schedule for your projects? Is the schedule up-to-date? How do you handle change to the schedule?

Michael Ryan is a technical editor with IBM Systems Magazine. Michael can be reached at michael@ryantechnology.com.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Are You Multilingual?

Rational enables development in multiplatform environments

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters