More from Karl Weigers

Karl Weigers, the author several books and articles on software requirements, has written another article found via a link on Dr. Dobbs.

It's more good advice, but as one of the commenters noted, it's advice that Weigers and others have been espousing for years, and I don't know about the dedicated software shops, but I know most IT shops are still missing the mark.

It's also interesting to note that Weigers talks about getting as much as you can right from the start, and of course it didn't take long for an agilist or two to point a finger and yell, "Waterfall!". Weigers tries to tell those posters that he didn't say "all the requirements have to be up front" but that there needs to be a solid foundation before people start hacking out code. But I don't think he needs to apologize for anything he said. Even Joel Spolsky has said he's been successful with BDUF.

Of course both sides have a point; it is also not wrong to prototype quickly (although in impatient organizations there is the danger developers will be told, "Oh, that looks good, put that prototype into production.") But how much of the requirements should be done up front? I think the severity of the cost of failure should have a play in how much needs to be done up front; if you're building the Saturn V rocket program for the Apollo space mission, or the F-15E Strike Eagle program, or medical systems software, damn it, you'd better have your ducks in a row up front or it's going to mean lost lives.

If you're a one-person team making a fairly simple card game as freeware on your own time, well, by all means, start hacking.

Somewhere in between those extreme examples are these silly things called multi-billion dollar companies that use software for everything from accounting to operations to customer service. I could be a real joker and say that perhaps it's good for the economy that so many corporate systems are broken and need lots of people to support them. But if you're one of the people stuck supporting broken systems, you might not find it funny as you spin your wheels trying to read arcane and undocumented hieroglyphics and wishing that you could be working instead on a new feature that would open up new options for the sales department.

Bad software is usually a result of poor requirements and it does cost companies more than they realize. But for a lot of them, the cost of failure is more payroll in maintenance and customer service...they're loath to pay it but some consider it just another cost of doing business. And if they're willing to pay it, then accept it, keep plugging, and refactor where you can.

Break Time

I just finished Susan Sontag's The Volcano Lover. It's an interesting book based on the lives of Sir William Hamilton, his wife Emma, and British naval hero Horatio Nelson. Sontag deftly blends the fictional with historical and does it with sumptuous prose. Sontag's life has been marked with some controversy and I don't agree with all her comments, especially those regarding 911, but I find her to be a brilliant writer and thinker. The book is peppered with interesting observations about life, and in taking a little break from work I'll capture some quotes here.

"...the news is always a little unreal, which is why we can stand to bear so much of it."

"A man who has to admire in order to desire is likely to have led a modest sexual life."

"You can look at the most apalling things in art. Whatever art shows, it is not going to get any worse. The knives are out...but his tormentors haven't started yet...to cut. Not even one tiny morsel of flesh. His monstrous punishment is forever only seconds away."

I'd read Sontag said "True art has the capacity to make us nervous." In the book, there is a passage that says the same thing in different words. I don't know if the quote is actually from the book and paraphrased, or if this is just Sontag saying it later in a different way, but it's a concept I've always found fascinating:

"We admire, in the name of truthfulness, an art that exhibits the maximum amount of trauma, violence, physical indignity. (The question is: Do we feel it?) For us, the significant moment is the one that disturbs us most."

"Acting is one thing, being civilized (which includes acting) is another."

"Nothing is more admirable than mercy."

Two More Examples of Business Analysis

I have two new Business Analysis stories to share. The first is a common pattern in recognizing that your business analysis approach is lacking. The second is a success story where I applied a lesson I learned from a previous BA class. Both are based on true stories though the names have been withheld to protect the author from frivolous lawsuits.

How did we miss that?
After a feature in a software application goes live, a support issue comes up and the development team lead and one of the developers are discussing it. The issue is one of functional deficiency; the feature works but is not accounting for some lower percentage edge cases. This deficiency is now costing the company more money than it realizes:

• The user raising the issue is unable to depend on the system to complete work
• The development team lead and the developer are both expensive resources now having to spend time fixing something rather than moving on to a newer and perhaps more strategically valuable enhancement.
• The infrastructure team has to add this to the list of items in the next scheduled release.
• The costs of having dealt with this in the software development phase would have been less expensive than it is now. Now, it incurs the additional costs of regression testing, additional documentation, redundant testing and more.

The team lead mutters out loud, "That's a missed gap. How did we miss that?" If this is happening regularly in your shop, it's a good bet your BAs could use a little more training and need to understand the value an analyst's effort provides. Even if you did not have time to develop for all the feature's edge cases, by paying some attention to them, you could have at least had a contingency plan in place (manual work around, system work around, alternative business process) to deal with the issue. Instead you now have to throw it over the wall to IT, where enough of these types of issues will cost you more than you spent on that project manager who got it done on time and on budget, but not necessarily on target.

Challenge the User (and the importance of understanding the domain)
Here's a more positive story. In my BA class in 2008, I noted that I loved one key line in particular: "BAs are not order takers." That statement proved valuable in a development effort I witnessed.

The request being addressed is to automate a process that users must manually perform. Ok, sounds good, that's always something IT is good for. But the analyst on the case originally performed as an order taker. Word for word, the user's request was put into a requirements specification. Now, that's already a far sight better than situations when the developers are given a single verbal sentence for a requirements document.

But the original request in this case says the automated process should not run on weekends, and should a scheduled day fall on a weekend, the process should know to run on the next business day instead. That's a request that is a perfect example of something that seems obvious to humans but can be tricky for computers: understanding when to delay the scheduled process adds complexity. The routine must now take into account what defines a business day, what defines a weekend, and whose calendar is defining holidays. Moreover, you cannot simply ask the routine to run on Monday if the regularly scheduled time lands on a Saturday because what if Monday is a holiday? The logic has to know how to handle various date collisions.

Our story has a happy ending, however, because the analyst involved in the requirements definition looked more closely at the user's needs and realised that the date concerns would have no effect on the routine. The requirement that the process run only on business days was not a meaningful business requirement at all, but a process quirk of the way humans did things. In actuality, there was no new business data being generated on the weekends or holidays, so asking the computer to run the process on the set day versus the next business day would not make a difference; you would get the same data regardless.

The analyst conferred with the user and was able to eliminate the date logic, which simplified the routine and the requirements. Cost savings: fewer database tables, simpler logic and fewer lines of code to read and maintain.

Question everything!

Contract vs. Full-time

I've made another job change and this time I've returned to a mercenary's trade. I'm a contractor now (sometimes called consultant in IT circles). There's a long story behind why I decided to do this (some clues to which were in the last couple blog posts) but in the end I looked carefully at where I was and made a list of "reasons to stay" and "reasons to leave" and though there were some good reasons to stay, there were a lot more reasons to leave. Maybe more on that in a future post, but speaking of contracting, IT consultant Paul Glen has penned another very good one for Computerworld's April 19, 2010 issue.

In the essay, Glen cautions against not taking a closer look at factors involved in the contract-to-hire issue. His advice is usually sound and is so here, but a few omissions reveal his proximity to the ivory tower. Glen notes that contract-to-hire can be a good idea for both parties, but that some contractors may not be good matches for full-time employment if they are really happy with the consultant lifestyle (superior monetary compensation, travel, constant variety in projects and people) and may grow disenchanted with a full-time role.

Let's stop and think about that for a moment. In a previous post, I said I didn't like the way most IT shops used contractors, largely because I felt these shops were giving the most intellectually engaging work and pay to contractors and treating their full-timers like second-class citizens. Well, I still think that's true, and sadly, I've thrown in the towel on my hopes that this would change.

Glen's dancing with a contradiction here that contractors are somehow less valuable to an organization than a full-timer, even as he admits the contractor's duties are "fun and lucrative". What? Are full-timers not supposed to like work that is fun and lucrative? Are they supposed to ignore that mentally engaging and challenging work is often given to contractors while they are asked to sit and guard a light switch? Should they be only the types that "will gladly go to work on your help desk" for the rest of their lives with no upward mobility or appreciation?

I ultimately believe that Glen and I are on the same page about contractors. What I don't like is the article's failure to mention that if Corporate America wants to retain the best talent and bring it in-house, then Corporate America needs to give people a reason to want to be full-timers. There needs to be something to distinguish the full-time role and it doesn't start with looking at contractors and full-timers and trying to set them apart. What companies need to do is stand behind the lip service they pay to the hollow chant of "we love our employees" that they continue to print in their annual reports and recognize the value of the intellectual capital an employee brings through experience, expertise, and commitment to a company's clients, and to recognize the cost of turnover and mediocre quality. This means doing the things I've mentioned in the past: investing in employees, providing some education, and building an environment where they can take initiative to make changes in processes or tools that lead to efficiency and value. A company cannot crush employee morale and then expect miracles to happen. Even the most passionate employee can reach limits, right Mr. Glen?

There is a sad and disturbing analogy for this discussion: the US military. The military is outsourcing several duties (security details, civilian support) to companies like Blackwater and Halliburton. These contractors are paid handsomely for their services; significantly more than the US's own line troops. The US soldiers risk their lives for a client whose appreciation is suspect in a difficult war where the opponents have the honor of cockroaches. As the young privates and seasoned sergeants and even the priviledged officers look to their flanks on the battlefield, they see security consultants zipping by with better equipment, relaxed rules of engagement, and fat wallets. The army may be a volunteer force, but I think they can be forgiven for asking the understandable question, "Why?"

People will say, "Oh, but the full-time government troops have honor and job security the contractors don't have." Perhaps, but honor and 25 cents won't even buy a cup of coffee, much less pay the rent for the wife and children awaiting their father's return. And the job security is an illusion; if war should wind down, the army will be under the same pressures the consulting firms will be to cut costs.

People will say, "Oh, but soldiering is a calling, like teaching, so they don't need money." No way, you don't get to use an excuse that flimsy. Screw Jerry Brown and his "psychic income" cat crap. The bank won't accept psychic payments for the mortgage.

So here's where I get off the tangent and back to the point (as the readers, no doubt, say "thank God"). Yes, the reason some people like contracting is because it is fun and lucrative. But it doesn't have to be that way. Companies can, without having to break the bank (which they're already doing for contractors), make the full-timer proud to be a full-timer, and make the contractors want to be a full-timer. It's simple economics and capitalism: be competitive. Make full-time roles fun and lucrative.

It starts at the top with management.

• Have the philosophy that your employees do matter. Don't just say it; believe it.
• Be cognizant of what the compensation levels in the market are and competitively maintain your people's salary and benefits so the thought of leaving never occurs to them.
• Actively recognize them when they do something that helps the company.
• Find good projects for them that are engaging and not just about guarding light switches. You were able to do it for the contractors, I'm sure you can do it for the full-timers too.
• Let them keep their skills up to date. I'm not saying let them create a custom application inventory of a dozen disparate languages and platforms (no one should want that), but understand that technology is both your job and your responsibility. When a technology or technique comes along that can save time, reduce production support, make users and clients happy, and help the company in ways even the CEO doesn't know about, take the initiative to promote it and materialize it even when the PMO and the business may not have it on their radar because technology isn't their job and responsibility.
• When the PMO wants to make a project happen in an unreasonable time frame, don't throw your staff under the bus for personal gain. Yes, there are emergencies when unpaid overtime is a necessity, but if you're doing your job, they are the exception and not the rule.
• When your employees do work unpaid overtime, recognize and show appreciation for it. The contractors get that appreciation built into their rate and ability to bill per hour. Your full-timers don't, and when they look into the flanks and see contractors getting richer while they get poorer for the same work, or worse, for fixing the contractor's errors, believe me, they ask "why?".
• Appreciate what the mantle of management means. It means managing your employees. Don't wait for your full-timers to ask for a raise or a mentally engaging project. Some of them won't; they'll just vote with their feet, especially if you've been the kind that has enjoyed saying no to them several times in the past.

Contractors and full-timers aren't all that different, especially if you have been the type to use contractors in the same way you would use a full-time employee. They are both human beings and while yes, there are some differences in what each individual wants, at the end of the day it needs to be recognized that everyone's really there to make the mortgage and pay for college tuitions. If management could be less about cost cutting and more about building an environment that encourages the attitude of wanting to deliver world-class results and quality, then maybe production support wouldn't be so heavy, your full-timers could develop into the crack team that could do it all, and the need to ask who would be a good contract-to-hire candidate would go away.

Don't like what I have to say? Don't worry, it's just a rant. And I'm not holding my breath waiting for Corporate America to change.

Passion vs Professionalism

Passion: a powerful or compelling emotion

Professionalism (businessdictionary.com): Meticulous adherence to undeviating courtesy, honesty, and responsibility in one's dealings with customers and associates, plus a level of excellence that goes over and above the commercial considerations and legal requirements

Another good one from Paul Glen
I've enjoyed reading Paul Glen's articles on IT management, but was more ambivalent on Two Cheers for the Passionless, in which he calls out the convention that passion is needed to do great work. His argument is that he prefers professionals to the passionate.

My first reaction was to ask, "What about passion for professionalism, or passion for quality?" Upon re-readings of the essay, I have relented somewhat in Glen's favor. He concedes in the writing that passion can be pivotal in certain types of projects, but that the average work of IT people is often routine and better served by professionalism.

It's never that easy though!
However, I still think my question, "What about passion for professionalism, or passion for quality?" deserves an answer. I've come across my share of IT workers for whom it's all "just a job" and frankly, the quality of their work reflected this nonchalant attitude. These individuals did not hone their skills by reading about and learning new techniques. They attack the symptom but not always the root cause of issues in production support. They do not do a thorough job in the analysis, design, development, and testing of new systems or enhancements. In other words, these so-called professionals were unprofessional.

Glen is right that it can be very difficult to sustain the intensity of passion for long periods, and that in the swing downward from a high there is a risk the practitioner becomes depressed or apathetic if not hateful. But I think we're confusing some of our syntax and semantics here. What is the term for an enduring, lower-intensity passion? I don't think there is one. Conversely, what do you call the cadre of uninspired workers for whom it's just a job? I don't think professionals is the right word.

Mutually Exclusive?
Perhaps passion and professionalism are not mutually exclusive. Someone can be both passionate and professional. Passion is more about motivation while professionalism is about how a person carries himself in doing work and dealing with others. Work requiring intensity, focus, and vision almost demand some passion especially when time is limited and a project needs sacrifices (such as unpaid overtime). I therefore believe Glen's definitions of passion and professionalism are narrow in the article. How do you explain the phrase "a life-long passion" if passion is something that cannot be sustained? How do you explain professionals that vary in competence and thoroughness? The phrase "over and above" in the businessdictionary.com definition of professionalism indicates an above average motivation.

In conclusion, I'll split the difference with Mr. Glen. Professionalism, and the competence and honorable behavior it implies, is what we should aspire to uphold. I think it's ok to have some passion for it.

Software Development Math

First, let me apologize for the previous blog post. I was in a disturbed state about a number of things, and that last post was all over the map. Sadly, my friend did pass away and the thought of his wife and young daughter continuing on without him is painful. We have no choice but to bear it.

-----

Have you seen the old joke circulating around the Internet called something like "The Math of Love"? It has some very funny observations about life illustrated in the form of equations. For example:

• smart man + dumb woman = pregnancy
• dumb man + smart woman = affair
• smart man + smart woman = romance
• dumb man + dumb woman = marriage

In the same spirit, here are some equations about software development that I've come across. I preface by offering that these are entirely my opinion and could be wrong. But if you find yourself laughing at even one of them, then I can't be too far from the truth.

Developers

• good requirements + good developer = good application
• bad requirements + good developer = challenged application + massive production support
• good requirements + bad developer = bad application + massive production support
• bad requirements + bad developer = bad application + massive production support
• developer that never has to support own work + always awarded projects = overtime for everyone else
• developer lacking business knowledge + software project = unhappy user
• humble developer + user interaction = forged relationship
• arrogant developer + user interaction = missed opportunity + missed gaps + unhappy user
• arrogant developer + never has to support own work + aversion to learning = charlatan
• developer + aversion to learning = outsourced

Project Management

• good project (on time and on budget) - good requirements = happy managers + unhappy users
• rushed project = overtime
• bad requirements = overtime
• poor project manager = overtime
• managers that think software development is easy = overtime for everyone except the managers
• unpaid overtime = happy manager + unhappy everyone else
• project manager + technical decisions = unhappy developer
• business analyst lacking business knowledge = bad application
• business analyst that fails to challenge requestor = scope creep + overtime + unhappy user
• executives that can't hack the truth = overtime
• overtime + bad requirements + bad developers = BUSINESS AS USUAL