System iNetwork

Software Development

September 23, 2005

How "good" is our software? -- A question for IT managers

Here's a surprisingly obvious question that IT managers don't often ask. Why not?

If you're an IT manager (or software development team leader), how many times have you asked the developers working for you: How good is our software?

If you're a developer, how many times has anyone ever asked you this question?

It seems odd (at least in my experience) that some variation of this question isn't posed more frequently. Certainly in many manufacturing industries, a lot of attention is paid to the quality of what's produced (as well as the cost, of course). And this isn't always done in an effort to improve quality, sometimes quality can be lowered to lower production costs and thus the price.

Most of us have some sense of different quality levels of cars, housing construction, audio electronics, etc. And there are even published specs on various properties, such as noise levels in sound reporduction (which, of course, don't tell the whole story).

I guess the reason questions about software quality are rare is that there may seem to be few, if any, simple and inexpensive ways to measure quality.

And so, to the real point of this post: How do you, or would you, measure "software quality"?

Here a few possibilities to kick off the discussion:

a. Number of detected defects per 1,000 executable source statements (or lines)

b. Same as a), but using weighting for seriousness of the defect (minor, severe, etc.) and/or time intervals (defects per month since release).

c. Same as a) and b), but measuring deficiencies, rather than defects

d. End-user satisfaction ratings (ease-of-use, reliability, functionality, overall satisfaction).

e. Code quality measures, such as using one of the "complexity" formulas, or review by a "master-level" programmer.

f. Performance test results; performance measurements from production use

g. "Maintainability" ratings by programmers who code revisions to the software.

Quality measurements are mostly relative, rather than absolute, e.g., between two programs or two versions of the same program. And they can be used in different ways, including:

-- Assessing whether a particular development practice improves quality in some way (user satisfaction, runtime performance, reliability)

-- Assessing comparative staff performance

-- Assessing comparative products from vendors (and to home-grown applications)

How do you think iSeries IT shops should approach the question?

-- Paul

Posted by on September 23, 2005 at 4:19 PM | Comments (19)

September 14, 2005

Are Web services and/or SOA important for iSeries?

SOA (service-oriented architechture) seems to be a big buzzword these days both within IBM and in the general IT press (e.g., Computerworld). From what I've learned so far, I'd describe SOA as an expansion of Web services concepts. Here are my working definitions:

Web services are applications that use a set of XML-based standards (SOAP, WSDL, UDDI, etc.) to communicate. The goal of Web services is to allow platform-neutral, language-neutral communications between applications.

SOA defines each application task or code component as a "service." These services are then joined together (a lego block analogy comes to mind) to build useful applications.

Are these definitions valid? The SOA definition still feels pretty vague to me, and there are certainly far more extensive definitions available.

I'm also wondering to what extent iSeries shops are interested in Web services and SOA? Does anybody have any practical implementation examples to share?

Posted by on September 14, 2005 at 6:05 PM | Comments (7)

July 6, 2005

Top ways to make a development project fail

Have you seen "classic" ways managers or developers cause a software project to fail? Add them to our list.

As readers of the June 7 Club Tech iSeries Programming Tips Newsletter know, I've recently been watching a development project go south because the project team has broken just about every rule I know for a successful development process. The results are predictable, but the staff is perplexed why the delivered code doesn't work and users are unhappy. That prompted me to come up with a list of "tips" to guarantee a development project fails.

Have you got a favorite "tip"? Share it with the rest of us as an iSpeak comment.

Here's my list ...

1. Follow a "Big Bang" approach to development. Have a few meetings to collect requirements and then go into your "cave" for months of diligent design and coding. Spring the code on users at a single two-hour "review" meeting with the expectation they'll suggest a few tweaks, and you'll be able to deploy with minor additional effort.

2. Impose your overall concept of how the application should work. Seek requirements and suggestions only within that framework. Never consider that you may not have "gotten" the way users conceive of their work and the context in which it occurs -- your experience with lots of other projects assures your concept is bound to be superior anyway.

3. Don't involve users in the day-to-day design and development work. They'll slow you down. Expect users to await your contact and then to provide immediate answers to lists of highly specific questions you present without any context.

4. Don't bother to educate the application "stakeholders" before asking for feedback or approvals. Assume users will grasp immediately your overall application model and all the clever technical elements you've incorporated in the design. Since your design is close to ideal anyway, it's okay if they don't fully understand the system you're proposing they accept -- depend on their faith in you as the "expert."

5. Don't worry about the accuracy or clarity of details in the documentation or presentations you give to users. You know you'll be able to fix mistakes and inconsistencies before or after deployment, so expect users to be satisfied reviewing your rough sketches of how the delivered system will work.

6. Don't plan time for users to have more than a few minutes "hands on" work with prototypes or pre-production implementations. Of course, you have to let users "touch" the system a little bit before you deploy it in production, but there'll be time for an hour or so of "thorough" training once the system is done, and that should be enough.

7. Assume that any technical concerns raised by users are just because they're not as smart or well-trained as you, the software "expert." Nagging questions about the application structure or details in how it's used can be attributed to the users' childlike understanding of application systems as sophisticated as the one you've designed.

8. Spend most of your time in the company of your IT buddies who sympathize with your having to put up with "idiot" department managers and "whining" users. After you've busted your butt trying to create the best system ever for these ingrates, you need a little comfort and reassurance.

9. When users complain as you prepare to roll out the application, explain that a deadline looms and you've already overspent your budget, so changing the soon-to-be-production system would cause serious disruption in the organization. Don't mention that delivering a flawed system will cause even more disruption or that the primary "disruption" you're concerned about is the impact of a missed deadline on your job security.

10. And lastly... Don't pay attention to what's really been going on around you. You already know how to run a project - you've done it for years. So there's nothing of real importance to learn from one more project that ends in chaos.
    

Posted by on July 6, 2005 at 4:34 PM | Comments (21)