Dear Entrepreneurs

"Regard your soldiers as your children and they will follow you into the deepest valleys; look on them as your own beloved sons, and they will stand by you even unto death." --Sun Tzu

An open letter to entrepreneurs, from someone who has worked for quite a few of you.

Normally, I go through a lot of examples and points and then summarize at the end. This one is important to me, though, so I'll give you the summary now. Up front.

Your company is your baby. Not mine. You're invested, not me. To me, you're a job. Just another employer. Unless you do something to get me invested.

In my experience, a good number of entrepreneurs don't quite get this. I get that your company is your baby. You've worked for it, lost sleep for it, and probably skipped a meal or two for it. To you, this is personal. But it isn't to me. Not right away, and not just because you hired me. If I'm going to be personally invested in your company, in your idea, you need to give both reason and opportunity to do so. And it's worth it. If you're just a job to me, I'll walk away as soon as a better one comes by. If I'm invested, I'll have to be dragged out.

To that end:

Just because you believe, doesn't mean I do.

Most software developers I've encountered fall into one of two categories. First you have the mercenaries contractors. They work for the people who give them the best compensation. And I don't just mean money. Pay, benefits, environment, all goes into it. But as soon as they see a better place, they're a developer-shaped puff of smoke in the air.

Then, there are the developers who want to work for the company they work for. Because they want to be a part of what that company does. Believe me- those are the guys you want. But you have to give them a reason. And that's the bit that, in my experience, many entrepreneurs overlook. They think that the fact that they know how awesome the company is, then any employee should, too. Automatically.

Look- I'm a software developer and I'm familiar with the territory. A lot gets asked of us, and we take a great deal of professional pride in delivering quality work. But there's got to be a better reason than "Because I said so". If I'm working 50-60 hours a week just because "That's policy", then I'm probably going to have my resume out in a couple of months. Definitely before my one year anniversary. If I care, then I'll do what needs to be done, but you have to give me a reason to care. 

I've worked at both extremes of this. One entrepreneur mandated 50 hours a week, minimum, 24/7 support, and made us track our time down to the quarter-hour. For few benefits, and frequent communication that profit sharing and ownership would only come to those who deserved it. Which was, at least at the time, no one. I had taken the job in order to gain a specific skill set. Once I felt I had it, I moved on. I had no investment in the company because the founder hadn't given me a reason to care.

I went to another startup. The CEO gave regular meetings, not just on how the company was doing but why they were doing certain things. He told us quite frequently that his vision was to change a market in order to put more power and more control, and thus more opportunity, in the hands of customers. He ended every meeting with "Welcome to the revolution!" He believed. More importantly, he got others to believe. Nights? Weekends? No problem. Answer questions while on vacation- sure. Why? Because I wanted that company to succeed- still do, even though we've parted ways. And even so, I'm a touch sad about having done so. Because I believed.

Sprint Planning Pt. 1: Stop with the Points Already

"Our culture thrives on black-and-white narratives, clearly defined emotions, easy endings, and so, this thrust into complexity exhausts." --Caroline Knapp

I've been doing a lot of reading and thinking about story points lately, and over time I have been edging toward what I now see as a necessary conclusion. Story points are meaningless. Even... Wait for it... POINTless. Yes, I just did that.

To recap, when planning a development sprint, it's customary to assign a user story a point value as a measure of... Well, to be honest, I really can't tell you what it's measuring. I can recap what people say about what it's measuring, however I've become skeptical of whether or not points are measuring what people think they are. And even moreso of whether or not it's a good use of time to do so.

Definition of a "Point"

Here's the root of my problem with story points. What are they and what do they measure? These aren't simple questions, either. If you read here, you get the idea that points are a measure of complexity. However, this StackExchange answer tells the reader that points need to be a measure of size, not complexity. Both will tell you that points are not a measure of time, but everywhere I've run into the practice, someone has always defined a point something along the lines of "What one developer can do in one day". Which certainly implies that points are used to give some measure of time. So I have a hard time getting started here, because I don't even know what I'm supposed to be measuring. Time? Size? Complexity? The amount of effort it takes for two women to have one baby? 

What's the Point, anyway?

I promise- I'll stop doing that now. Maybe talking through why we need points, we can come to an agreement on what they are. We need them for estimating, right? But estimating what? The amount you can do in a two week sprint? The amount of time you need to finish a certain set of features in a product? After all, you assign points, add them up, and divide by about what your velocity has been, right? Because that works.

Except, of course, it doesn't. Addressing the latter poi ISSUE ::ahem:: first, we all know that doesn't work. Regardless of what some may say, points do not mean you don't need to re-estimate. Software development is a process that builds on itself with every build adding to the whole an impacting the effort/size/complexity/time needed for future changes. I'd be very dubious of the point value of any story not going into the next sprint. I'd be even more dubious of any time estimates derived from arithmetic on points, velocity, and time.

So, maybe it's a good way of determining what can be worked on in the coming sprint. Problem is, without definitive answers to the question "What does a point measure", using points to determine what stories can fit into a sprint is a terribly uncertain process.

If we take the definition of points being a measure of the size of the story, then we truly have no idea how long a story will take. In fact, the StackExchange user in the link I referenced illustrated this very thing. He gave examples of the complexity of a 5-point sized story varying by a number of factors, leading to wildly different completion times. I don't really see that as a practical way to plan a sprint. More importantly, I don't think the people who expect me to plan sprints will see that as a practical way of planning sprints.

If we take the definition of points measuring complexity, we run into a different problem. How do you measure "complexity"? It's not like defining the length of a metre or defining a joule. the only way is to compare the complexity of one thing to the complexity of other things until you get something that feels like a match. Inaccurate, sure. But that's why it's called "estimating" and not "precision". I'd be basically okay with this except for a couple of things:

1. That which is complex to one developer may not be to another. Planning Poker is supposed to account for this, but it doesn't. In fact, it ironically exacerbates the problem it claims to solve. My 5 point complexity story may be another's 2 point complexity. To assign it 5 or 2, then, is meaningless outside the context of the developer who will be working on it. And splitting the difference to make it 3 or 4 is just compounding the uncertainty of an already uncertain process.
2. Complexity has nothing to do with the amount of time it takes to do the task. Planning Poker assumes that every developer handles every type of complexity in the same way and at the same pace. Maybe one guy tackles a complex story by diving in and coding until he grinds to a solution. Maybe another takes time to read more on the subject, asking questions, and only starting when he feels he has a better understanding of the subject. Given this, complexity can only correlate with time if every developer approaches complexity the same way.

Either way you look at it, you're trying to objectively quantify a series of subjective data points. Logic 101 tells us that this is a highly inaccurate way of measuring anything.

Velocity

Finally, we get to Velocity, which I'm pretty sure is the whole reason we bother to keep track of points in the first place. Velocity is nothing more than the sum of the points of the stories in a given sprint. It purports to measure the amount of work done in a sprint so you can compare to other sprints and then plan a timeline for future features.

Where to start.

First off, all this gives you is a comparison of how you've been objectively quantifying the subjective sprint over sprint. But as a comparison of the actual work done? All you're doing is comparing arbitrary numbers to arbitrary numbers and pretending it's a meaningful measure of productivity.

Secondly, using this as a future planning tool is a recipe for disaster. In order to make that work, you'd have to give point estimates to everything in your backlog and then continually refine those estimates in light of what the previous sprints have accomplished. Do that for long enough, and sure. your velocity will become a more and more accurate tool for predicting the amount of work the team can handle. But at what cost? At what time commitment?

Conclusion (WHEW!)

I'm not saying we need to stop estimating anything. Projects, stories, releases, versions, whatever unit of work that is needed, all need to come with some idea of what it takes to accomplish them. What I am saying is that we need to re-think the whole point estimation bit and ask ourselves if this isn't just an overly complicated process. Effort, complexity, productivity- these are all complex issues that are impossible to quantify in a simple context. Maybe we need to stop trying. Because I really hate unnecessary complexity. I'm not even much of a fan of necessary complexity. I'm lazy and don't want to work any harder than I have to in order to solve problems.

Next article, what I see as the real root of the problem and what I have started doing about it.

Life is Agile

"It's not what happens to you, but how you react to it that matters" --Epictetus

I'd like to pose a question to any parents reading this. When your child was born did you plan out every detail of your child's life? Did you attempt to account for every problem and develop a contingency plan before even leaving the hospital?  Do you parent in a vacuum, having no contact with other parents?

Similar question to those of you with active careers, be it in the job market or at home. Yes- being an at-home parent is a career. Did you plan out every step of your career before you began working? Do you work without interaction with others in your career? Did you plan for every problem to the most minute detail?

Of course not. To approach such a major endeavor in life is more like planning to fail. And this is why Agile is the only way to successfully complete a software development project of any consequential size. Because it mimics human behavior and human capabilities. At it's core, the Agile methodology is an admission that you can only do so much to plan for the future. It's a system built on the foundation of communication with others. It does not merely recommend regular and effective communication, it states that failing to do so will cause overall failure. It is built around doing what you need to now, while keeping an eye on the future. Similar to how you eat an elephant (one bite at a time), so do we manage our lives. Why should we assume that managing a development project should run so completely contrary to our fundamental behavior?

The converse is also true. It's been a very long time since I've had to defend Agile vs. Waterfall/BDUF. The reason appears very straightforward- the proof is in the doing. Agile has proven itself. It's not theoretically better, it simply is.

How, then, can we extrapolate this to our lives? Should you find yourself working at a company where you have no future, what do you do? Do you scrap the idea of working at your best capacity while you look for another job? Agile says differently in that a development team has the discipline to finish a development sprint, i.e. the work in front of them.

If you want something in your career, do you just keep working and hoping it happens? One of the foundations of Agile is communication. Do we keep grinding and hope, or do we approach others for advice? And then do we approach management and clearly communicate what we want?

Life is Agile is life. The lessons we learn from each can be applied to the other.

Healthcare.gov failures in leadership

"Good management consists in showing average people how to do the work of superior people." --John D. Rockefeller

"Good management is the art of making problems so interesting and their solutions so constructive that everyone wants to get to work and deal with them." --Paul Hawken

Yep. I'm back at this well. Partially because it's a great way to boost hits (I don't use ads, but I do have an ego) but mostly because I've been there. Not in a project this size, but I've lived the nightmare. Maybe someone that can affect this boondoggle

reads this and listens. Likely not. I have an ego, but I'm a pretty small fish. More important to me is that the developers and IT staff affected by projects like this understand the failings so that they know when to update their resume.

This one is coming from a New York Times article titled Inside the Race to Rescue a Health Care Site, and Obama. And again, whether Ms. Stolberg and Mr. Shear realize it, they paint a picture familiar to many IT veterans.

Failures of Testing

I've written about the technical failures of the development teams but what has been written in this article serves to underscore something all development teams know, but fewer do. Testing. From the article:

"To do that, they would have to take charge of a project that, they would come to discover, had never been fully tested and was flailing in part because of the Medicare agency’s decision not to hire a "systems integrator" that could coordinate its complex parts." 

"The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered." 

"'There’s so much wrong, you just don’t know what’s broken until you get a lot more of it fixed,' Mark Bertolini, the chief executive of Aetna, said on CNBC."

Regression testing. Unit testing. User Acceptance testing. I can't think of a better way to talk about the dangers of not budgeting time to properly test your project.

"In Herndon, as engineers tried to come to grips with repeated crashes, a host of problems were becoming apparent: inadequate capacity in its data center and sloppy computer code, partly the result of rushed work amid the rapidly changing specifications issued by the government."

Code reviews and proper architecture concern would have prevented the "sloppy code" issue. The rest of this segueways nicely into my major point, thought.

Failure to understand a software development project

Clearly, project management didn't know how to manage a large-scale project. I've said before that the evidence could not be clearer that this project was managed Waterfall-style. And while the far-preferable Agile development style can also struggle with changing requirements, the iterative workflow, combined with constant checkpoints with the business stakeholders allows for better options for dealing with the fact of life that is spec change. Here are a few examples from my playbook:

"No, we will not change specifications in mid-sprint. If you want this change, submit it to the Icebox and give it a priority. We will then do the design and estimation work and add it to a future sprint."

"No. This is a two week sprint. We will not finish early. We will not rush. We have a planned amount of work that will take two weeks to deliver properly."

"No, we will not add to this sprint. The sprint covers an amount of work that can be accurately delivered in two weeks."

"No, we will not include this work into a sprint until there is proper user acceptance criteria attached. The delivered code will then conform to the acceptance criteria listed. No more, no less. I'm here to help you write good acceptance criteria."

Enforcing this kind of project discipline is crucial. It should be well-communicated up front. Everyone should know what an iceberg is. And once the expectation is set, that expectation is enforced. But even with that, the problem runs far deeper. Some quotes from the article really chilled me:

"Out of that tense Oval Office meeting grew a frantic effort aimed at rescuing not only the insurance portal and Mr. Obama’s credibility, but also the Democratic philosophy that an activist government can solve big, complex social problems." 

"'We’re about to make some history,' she (Ms. Sebelius,) said.

"...reveals an insular White House that did not initially appreciate the magnitude of its self-inflicted wounds"

As any regular readers know, my overall philosophy comes from Marcus Aurelius:

“This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee.”  

By itself and in its proper constitution, Healthcare.gov is a website that allows people to purchase health insurance. It is not a justification of a political philosophy. It's not about making history. Those are incidental. You cannot make good decisions if you don't understand the context for those decisions. You can't make good decisions about a development project if you see it as anything other than a software development project. And don't think for a second that minimizes its importance somehow. Most developers I know care a good deal more for their code than they do your politics. But if management mistakenly sees a project as some kind of ideological movement or as setting their legacy then they aren't making project management decisions.

Management culture

Finally, what may be the worst failing of the management of this project. It's culture. The standards management sets for its operations. The only place I've ever heard of management leading so poorly is in Dilbert. For example:

"For weeks, aides to Ms. Sebelius had expressed frustration with Mr. McDonough, mocking his “countdown calendar,” which they viewed as an example of micromanagement."

Mocking other stakeholders. Ignoring, for a moment, the notion of expecting professionals to not act like spoiled children, why was this behavior considered acceptable? Management sets the standard for how people act. A good manager understands this. A good manager sets an expectation of professionalism. Complaining is one thing. Open mocking should be the sort of thing people are embarrassed to do, or even to listen to.

"Contractors responsible for different parts of the portal barely talked to one another, hoping to avoid blame."

There's enough written about how a management culture of blame creates a toxic environment. Problems aren't addressed. People pass the buck rather than address problems. The concern is to not be left holding the bag, rather than making sure work is done well. Fear does not create quality. And clearly, this is not known here.

 "Mr. Obama, meanwhile, was under assault. After years of telling Americans, “If you like your insurance plan, you can keep it,” he was being accused of lying. On the night of Oct. 28, Ms. Jarrett, one of Mr. Obama’s closest confidantes and a guardian of his personal credibility, took to Twitter to defend him — and to shift the blame. 

“FACT,” she wrote. “Nothing in #Obamacare forces people out of their health plans. No change is required unless insurance companies change existing plans.”

The tweet touched a nerve; it was not the first time the Obama White House had used the insurance industry as a scapegoat. Ms. Ignagni’s (chief executive of America’s Health Insurance Plans,) members were furious. “Here it comes — we knew it would happen,” one executive recalled thinking."

 The Obama administration built support for the ACA by building hostility to the insurance industry, with whom they must now work. So, in essence, the Obama Administration has taken every opportunity to publicly condemn the insurance industry and is now relying on that same industry to launch not only it's centerpiece website, but the validation of their political philosophy. A management team that does not treat their vendors with respect will find themselves very lonely once they need their vendors. UnitedHealth and CIGNA have already "mostly shied away from the online marketplace" (From the article). To assume this has nothing to do with the administration's clear contempt for their vendors is folly.

I have a difficult time summing up my shock at the sheer number of leadership failures involved here. Not just in knowing how to run a software development project- clearly Medicare and the Dept. of Health and Human Services considered this a "Fire and Forget" project and that they were absolved of all responsibility to be involved once the project started. More disturbing, though, is the culture that management allows. Childish behavior and finger-pointing should not be acceptable. And that attitude starts from the top.

The Unambiguous Measure of Success

"[T]he presence of an unambiguous measure of ex-post success (profit) serves to harness the natural tendency toward overoptimism that otherwise would almost certainly be present when someone else’s money is being spent." --Robert Wagner, "Economic Policy in a Liberal Democracy"

Every once in a while I'll come across a quote or an article that makes me think about software development. Often that's because I tend to read a lot of material related to software development, but sometimes it's not. Such is the case of Donald Boudreaux's Quotation of the Day for October 23rd. The full quote is:

[T]he presence of an unambiguous measure of ex-post success (profit) serves to harness the natural tendency toward overoptimism that otherwise would almost certainly be present when someone else’s money is being spent.  The necessity of putting one’s money on the line and of being responsible for the ultimate outcome surely has a sobering effect on the assessment of the prospects for such projects [that governments typically undertake], an effect that is weakened when tax money is used in a setting where no judgement about profitability has to be faced.

I'm no economist and I don't pretend to be one. And this isn't a post about economics, anyway. What caught my eye was the idea that putting one's money on the line and being responsible for the ultimate outcome by setting an unambiguous measure of success. Even though we all know, often through painful experience, why clear and unambiguous project goals are a necessity, I think it's interesting to look at it with an economist's viewpoint.

Instead of "someone else's money is being spent", let's use "someone else's resources are being spent". In other words, not just the salaries of development staff but also time and infrastructure. If the burden of this is borne solely by the development staff, then the tendency of the customer stakeholders is toward overoptimism. Features, both initial and scope creep, and timelines all trend toward pushing the limits of what the development staff can reasonable accomplish. At least, that's been my experience.

A couple of things happen when the customer is expected to give a clear and unambiguous measure of success. Not just in terms of a requirements document, but close involvement in the development process both in defining clear acceptance criteria for user stories and in reviewing the results of development sprints. The customer is now spending their resources on the project. Their staff has to be available for clarifying requirements. Their staff is has committed their time to insuring that the "measure of success" is being met. And their staff also has to budget, and therefore use effectively, their time for the project in relation to the time needed for other tasks. The tendency of those with a stake in the game is to be more careful with how those resources are spent and to insure that resources aren't wasted. I guess this makes sense, really. People tend to spend money more frivolously when not using their money, or when it doesn't look like they are using their money. It's why managing credit can be tricky and it's why casinos use chips instead of currency. Why should spending resources on a project be any different?

I like this quote. It's a truism of software projects, for that matter projects in general, that you can't finish a project if you don't know what "finished" looks like. I'd never stopped to think about how a clearly defined measure of success affects the customer in a project.

Health Care Exchange Project Pt. 3

"One test is worth a thousand expert opinions." -Wernher Von Braun

And finally the last piece of the puzzle. As a software developer, I find the previous types of project problems maddening. However, this last category boggles my mind. Perhaps I'm just an idealist, but I truly want to believe that this sort of thing doesn't happen anymore. Sadly, I read The Daily WTF far too often to really believe it. We are now down to technical failures.

Again, quoting from From the Start, Signs of Trouble at Health Portal

"Others warned that the fixes themselves were creating new problems, and said that the full extent of the problems might not be known because so many consumers had been stymied at the first step in the application process."

"'So much testing of the new system was so far behind schedule, I was not confident it would work well,' Richard S. Foster, who retired in January as chief actuary of the Medicare program, said in an interview last week."

We all know that maintenance, especially bug fixing, is the true bulk of any software development work. And we all know that testing is the heart of finding, and therefore fixing, bugs. This is not under dispute. However, I've been associated with so many development projects that ignore this basic principle that I want to weep sometimes. And it's always the same. "We don't have time to test because we're busy building features". Or "We'll focus on testing later". Or the worst, "We'll worry about bugs when they're reported by users". (Yes- I've been told that)

To be clear. Unit tests insure that a unit of code has a consistent result at any point in time. It doesn't insure that the code does what it is supposed to. It insures that what the code does hasn't changed due to other factors. Unit tests are how you do regression testing. At least, how you do it without resulting in Cthulhu-level madness.

User Acceptance Testing insures that the users can actually perform the tasks called for in the specifications. This doesn't happen at the end of the project. This happens at planned stages throughout the project so that testing happens on a manageable set of features. A set of features that can be easily documented, easily described, and easily managed. Failure to do this step before rollout is inexcusable.

And while we're at it, what about Exception handling testing? What effect does any given exception have? How is it reported, both to support and to the user? How are exceptions tracked? Testing isn't just about making sure the application works well. It's about insuring that it fails gracefully.

"The biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring (Em. mine- MO), according to people familiar with the process."

I'm pretty okay with most of this, but the failure is so bad that it's worth mentioning. The award amount doesn't bother me. I'm also pretty okay with two years of requirements. This isn't like turning on a switch and watching everything work. This is a serious development project- far more serious than anything I've participated in. I would have been more surprised to see the award amount or the planning time significantly lower.

But read the bit I emphasized. Development didn't start at any point during planning. In other words, a project with this level of work and complexity was attempted Waterfall-style. Not Agile. Waterfall. In a project like this, the technical leadership deliberately passed on the ability to easily reach to changing requirements. And the ability to work on completed requirements as they become available. And on increased involvement between development and stakeholders. And continuous testing.

I'll take the heat for saying this- Agile isn't a buzzword. It isn't a topic for bloggers to discuss. And it isn't an alternative methodology. It's the only sane way of approaching a development project of any more than a trivial size. You simply can not anticipate everything ahead of time, and attempting to do so harms the project more than it helps. Case in point.

All of the problems the NYT article describes are serious. Any more than one or two of them will probably sink a project. The fact that people are reporting this many fundamental mistakes makes this an example everyone familiar with software development should understand. If only to protect your career.

Health Care Exchange Project Pt. 2

“No matter how good the team or how efficient the methodology, if we’re not solving the right problem, the project fails.” - Woody Williams

In my previous article I started talking about the New York Times article From the Start, Signs of Trouble at Health Portal. See previous article for the disclaimers that hold here as well.

In Part Two, I want to talk about the parts of the article that, to me, describe a major failure in project leadership. Not to be confused with executive leadership. In this case, the described failures in those responsible for the actual project leadership.

"Failure to plan is a planning to fail". It's a cliche for a reason. Starting a development project without a plan, or with an obviously flawed plan, is a massive waste of time and money. From the article:

"Dr. Donald M. Berwick, the administrator of the federal Centers for Medicare and Medicaid Services in 2010 and 2011 'The staff was heroic and dedicated, but we did not have enough money, and we all knew that,'"

From the beginning, we have a serious issue. The project wasn't funded.  The only way this works is if you have a plan to scale back what you can't pay for. The quotes in the previous article regarding executive leadership make this an impossibility, however.

 "Some people intimately involved in the project seriously doubted that the (Medicare and Medicaid) agency had the in-house capability to handle such a mammoth technical task of software engineering while simultaneously supervising 55 contractors."

"The political people in the administration do not understand how far behind they are." 

Well, now we have some insight into some of the executive leadership issues. Project management is supposed to be responsible for insuring that the correct groups are responsible for units of work and are responsible for reporting progress. It very much sounds to me like the project management team fell flat here. This is by no means unique to ACA, nor even to government development projects. I've seen, far too often, project managers who think their job ends with the kickoff meeting. Or who only schedule meetings and do little else. A good sign of a sinking project is negligent project management. Worse is project management that is unfamiliar with what the role entails.

"A round-the-clock effort is under way, with the government leaning more heavily on the major contractors"

"Worried about their reputations, contractors are now publicly distancing themselves from the troubled parts of the federally run project."

"Senior executives at Oracle, a subcontractor based in California that provided identity management software used in the registration process that has frustrated so many users, defended the company’s work. 'Our software is running properly,' said Deborah Hellinger, Oracle’s vice president for corporate communications."

How often have you seen this story play out? Lack of planning and poor leadership lead to "crunch times". As a result, development staff is required to work late. Demands raise past what is reasonable and soar up to the ceiling of what is possible. The result?  Discontent and CYA. The quotes above tell me that the contractors have already given up on the project and its leadership. Worse yet, the "blame game" has gotten into full swing. Blame doesn't happen when the project staff sees the project as salvageable. Blame only happens when the project is seen as a loss and people only want to salvage their careers. In a very real way, the blame game prevents problems from getting fixed.

Project management problems are a warning sign that is difficult to see. Oftentimes, poor project leadership isn't obvious until the project is well under way. At that point, recovering the project can be problematic. Tasks have already been assigned inappropriately, Reporting is either far behind or nonexistent. And at the worst, although I didn't see any evidence of this in the article, poor project management often involved a lack of clear project goals. This last is, in my opinion, the worst way project management can fail. If a project without clear end goals is allowed to continue, failure is the only possible result.

Health Care Exchange Project Pt. 1

“I have witnessed boards that continued to waste money on doomed projects because no one was prepared to admit they were failures, take the blame and switch course. Smaller outfits are more willing to admit mistakes and dump bad ideas.” - Luke Johnson

Let me start off saying that this isn't political commentary. If you want to talk about whether or not the Affordable Care Act (ACA) is a good idea or should be repealed, please go elsewhere and don't pollute my blog with political commentary.

Earlier today, I came across NYT article headlined "From the Start, Signs of Trouble at Health Portal" and written by Robert Pear, Sharon LeFraniere, and Ian Austin. Before going on, I highly recommend reading the article. I also found a very readable companion piece written by Megan McArdle.

The reason it caught my attention isn't that it is about ACA but rather the amount of project failures that I can relate to. The signs of common project management mistakes are so obvious, anyone experienced with software development projects will find themselves nodding their head with nearly every paragraph. This article doesn't describe a mere failing project. The failures described here are so blatant, so numerous, that I have to wonder if we're looking at deliberate sabotage. Or possibly the article is merely social satire.

The point of this isn't to slam the ACA, let me make that clear. The desired end of the project isn't what caught my attention. Nor am I trying to "discredit" the ACA. This is a real world study of how to run a software project into the ground and guarantee its failure before the first line of code is written. This article should, absent all else, serve as a warning to those undertaking software development projects, and indeed projects of any kind.

As this is far longer than my usual blog posts, I'm breaking it up into three parts, by what I see as logical categories of the project's failures. For the first one, lack of executive leadership.

It's frustrating when software projects are crippled by executive-level politicking. Executive-level leadership is foundational to a project's success. And like a building with a flawed foundation, poor executive leadership will destroy a project in unexpected ways. I have been involved in several projects that lacked executive-level leadership. All collapsed. Quoting the NYT article:

"Politics made things worse. To avoid giving ammunition to Republicans opposed to the project, the administration put off issuing several major rules until after last November’s elections. The Republican-controlled House blocked funds. More than 30 states refused to set up their own exchanges, requiring the federal government to vastly expand its project in unexpected ways."

"Administration officials dug in their heels, repeatedly insisting that the project was on track despite evidence to the contrary." 

"Mr. (Henry) Chao’s (Chief digital architect) superiors at the Department of Health and Human Services told him, in effect, that failure was not an option, according to people who have spoken with him. Nor was rolling out the system in stages or on a smaller scale, as companies like Google typically do so that problems can more easily and quietly be fixed." 

I see a few serious warning signs here. First, not all stakeholders were on board with the project. I don't care what rationale you use, if the stakeholders aren't on board, the project is doomed. This is as close to political as I want to get here. Neither the reasons the Democrats had for steamrolling the Republicans on the ACA nor the reasons the Republicans have for trying to kill it matter in this context. The unassailable, unarguable, truth is that if a major stakeholder want to kill a project then the project is dead. Ideology does not change this, nor does intent. Whether the result of the project is necessary, helpful, or detrimental is also irrelevant. And it is inexcusable for executive leadership to begin a project like this, through intent or ignorance of This Law, with such high level opposition.

Just as bad, however, is the unwillingness to acknowledge that the project is in trouble, but rather relying on the "Failure is not an option" method of resuscitating a project. Take a moment and count the number of times someone told you "Failure is not an option" or "Just make it happen" and it actually helped. Go ahead. Raise your hand if you got a number above zero. Anyone out there have their hand raised?

Didn't think so.

Attention all managers- these phrases do not solve problems, nor do they create an environment in which problems can be solved. For the love of all that is holy, stop using them.

Several reasonable suggestions are on the table. Postponement. Small scale rollouts, Google-style. The reasons given for ignoring these options are just about the worst possible. Executive-level politics.

Executive leadership enables development projects in ways that many people on the project never see. Because of that it's difficult to see when executive leadership is failing. Sadly, the results are less hidden.

Tips for Standing Out

"If you don't get noticed, you don't have anything. You just have to be noticed, but the art is in getting noticed naturally, without screaming or without tricks. --Leo Burnett"

Recently, I have been going through our family digital pictures. There's quite a lot of them, and I'm afraid that I haven't been great about any sort of categorizing or even avoiding duplicates. So, with literally thousands of digital pictures, I'm sorting, organizing, and moving them to cloud storage. In going through them, I started wondering. I had just gone through 30+ pictures of dolphins at a zoo and was currently looking at almost fifty pictures of a gift exchange at Christmas (more pictures than there appeared to be attendees), and I started considering the value of an individual photo in the age of ubiquitous digital cameras.

Sure- I could have organized the images in a given folder by general context and then subordered the images within a context by general worth. Color and lighting quality, view of the subject of the photo, etc. Establishing a baseline to determine which photos are worth keeping and which are not. And after a great deal of time and effort, I could have come up with the absolute best images to keep.

I didn't. I deleted something like 80 images because after picking out a few that represented the scene or event, even going through the rest of them to see if there were any other good images simply wasn't worth the time. The value of each individual image was very low. If it didn't immediately stick out as worth keeping, it wasn't even worth the time to look further at the image.

It shouldn't be difficult to see where this is going, but let's keep moving, shall we?

So how do we, as developers, stand out from the crowd. It's tempting to believe that consistently delivering quality work will to this, but let's face facts. In this world of development teams, project teams, and managers that have so much on their plates that things just naturally fall through the cracks, this simply isn't true. Nope- not even for you. (Mostly directed at 10 Years Ago Matt, who honestly believed just this.)

So what helps people stand out? When a manager thinks of your department or wants to assign a person to a task, what can make you jump into mind?

How to Stand Out

1. Don't be afraid to pitch ideas. Don't come off as critical and certainly make sure you aren't taking time away from something else. But don't be afraid to try. Code is best communicated through code so don't rely on the clumsiness of spoken word to communicate your code ideas. Build a demo. Cite sources. Make a pitch.
2. Talk to people. When you talk informally with colleagues or even, if your organization allows this, superiors, you have an opportunity to discuss ideas outside the delicate context of "Here's a change I think we need to make". This gives a degree of safety to the discussion- you're not proposing invasive changes, you're talking shop. You're exchanging ideas rather than making a pitch. Again- don't be critical and don't be a pest. But participate in the developer community of your office. People remember contributors. "Head down, mouth shut" often also means "forgotten".
3. Don't be afraid to ask for things. Is there a project you want to be a part of? Is there another role you'd like to fill? Ask. Maybe the decision maker will agree with you and maybe not. But your odds of getting what you want increase sharply when you communicate what you want.
4. In order to do #3, you really need to take this step. Be honest with yourself on what you want and what you can do. A central theme to everything I've said here is that you cannot properly use something you don't know and understand. That includes you. Want to become a Development Lead? Understand, then, your leadership abilities and how you can best display the skills necessary for the job. Asking is important, but if you can't show that you fit what you want, then you won't get what you want.
5. Be the guy that asks questions and offers solutions. Everyone can criticize. Even if they're not being critical, any good developer can summarize a problem. The trick is to be the one trying to help reach a solution.

How to NOT Stand Out

1. Brag. We've all created elegant code and we've all come up with clever solutions. And we all like to talk about them. But there's a line between talking about things you've done and bragging. If you never talk about your accomplishments, chances are that no one will recognize them. If you brag, chances are no one will care.
2. Butt in. Again, there's a fine line between offering help and butting in. Chances are, if you're the guy that always has a better solution and can't let even the smallest issue go by without comment, you've crossed that line. This, too, will make you stand out.
3. Criticize. You want to offer solutions because they think they can help. Great. But if you want to offer solutions because you think the current implementation is bad/stupid/incompetent then you'll definitely stand out from the crowd. Just not the way you want.

Let's face it. There are a lot of developers out there. There are even a lot of good developers who deserve to stand out. But it's not the job of other people to notice you. It's your job to be noticed for adding worth to what you do.

Why Bad Code Won't Die

Let's face it. Code goes bad. Maybe, due to technical debt, it started out bad and now it's time to pay the note on your debt. Maybe, due to a new version of your software platform, there's a better way of handling what your application is meant to handle. And maybe your application is now handling situations that were not taken into consideration during development, whether anticipating them was reasonable or not. Whatever the reason, what was once perfectly acceptable code often becomes obsolete.

The challenge isn't writing code that won't go bad. You do your best, with the realization that it might just happen anyway. The real challenge is getting the situation resolved, because you can't just charge in and make changes- at least, I hope you can't. It's a sad fact of the developer's life that projects like this may be necessary, but are often rejected, leading to frustration and a lack of confidence in leadership.

It's a common failing in communicating with others. You assume that things that make sense to you make sense to others and that things that have value to you have value to others. It's human nature, really, to assume that the context in which you view life is the context in which others do, too. Because improving the quality of your code is important to you, makes sense to you, and is just intuitively obvious to you, you tend to assume that it is to others. Then you construct your communication, consciously or not, along that assumption.

The problem is that most development managers and just about everyone higher than that on the corporate totem pole view project priority in a completely different context than developers do. And since they hold the final decision on whether or not a development project gets green-lit, it's critical to understand why "Yes" to projects, why they say "No", and the thought process that goes into that decision. If you can tailor your pitch to the way upper management thinks then you can at least communicate your need in a way they understand. This, of course, doesn't guarantee anything. But you at least avoid getting in your own way.

Developers tend to consider a well structured application as the end goal in a project and as the motivation for taking, or not taking, action. Which is good- that's what they're there for. The problem is that upper IT management rarely, if ever, evaluates projects through that lens. To them, risk is the key decision point. Not just the risk of breaking something else due to the changes, either. Risk to the project schedule as a whole. Risk involved in an application changing- even if it's for the better. Users get used to the way an application works and there's often resistance to change. The unfortunate truth is that, in the mind of an upper manager, "This is better code" never trumps "This is currently working". Attempting to approach a "Code Improvement" project from a technical point of view will rarely work. In fact, it has never worked for me. Not once.

The first thing you need to do is explain the necessity for the change in the point of view of what is important to upper management. If you can't do that, learn to suffer in silence because this change will go nowhere. Since upper management's priority is a low risk of interrupting business processes, it is critical to show that not making the desired changes will lead to a greater risk of interruption than not making the changes. Risk of application failure is a great thing to focus on. So is inability to support known, or likely, business needs in the future. If the current state of the code is no longer performing well due to increased load, point out the trend in increasing load and try to project a timeframe for the application no longer functioning. Are there upcoming needs that either can't be supported given the current state of the application or can be implemented in a greatly reduced time given a change? Have hard numbers and facts. State the known needs that can't be implemented and how that impacts the business. Show how a project can be completed more quickly if the desired change is done now. Remember- upper management cares about how well the IT department, as a whole, can support business needs as a whole. Present your case in terms that are important to your audience.

Second, have a plan. Don't just outline a problem and dump the mess in someone else's lap. Explain how the problem can be fixed. Go on from there to how long you think it will take- remember, your audience is thinking in terms of a schedule of many projects. Scheduling an unanticipated project impacts the rest of the project calendar. Make sure your audience understands the impact and that the impact is worth it. Then outline the risks. This is important because as soon as you give your opening argument, your audience has already started thinking in terms of risk. Then present how you will handle that risk. Will other applications be affected? How will you minimize the impact on those applications. Will this change business processes? How can IT work with the affected business units to make sure they understand how to interact with the changes. What happens if something goes horribly, horribly wrong? What failure points will you be looking for and what will you do if they do fail? How will you minimize the impact of a massive failure on the business, how will you fix the failure, and how much effort might it take? How will the project calendar be affected, what projects may have to be put off in order to do this, and what can be done to minimize the overall delay?

None of this, of course, guarantees success. I've made pitches like this and heard the equivalent of "I understand, but we want to focus on new feature development". Or, "I'll take a closer look at this and see if we have time on the project calendar." Which is often a long way around of saying "No". Sometimes upper management simply isn't interested or just doesn't want to accept the risk. This happens. But management is never willing to accept risk they don't understand or change that doesn't seem beneficial. It's your job to communicate the need to fix bad code in a way that the decision makers will consider a high priority. If you understand how the decision makers think, you understand how to communicate with them.

Which, if you think about it, goes for life in general as well.

Painting Fences

Imagine this exchange, if you will:

Homeowner: We need to to paint the outside of our fence white.
Contractor: No problem.

(2 weeks later)

Homeowner: I know we asked you to paint our fence white, but now we need it painted red.
Contractor: You don't like the white?
Homeowner: It's not working for us, and we'd like to try red.
Contractor: No problem.

(2 weeks later)

Homeowner: Okay, sorry about this but now we want our fence green.
Contractor: Sure, I can do that, but I have to ask. Why the color changes?
Homeowner: The neighbor's dogs bark all night and we're trying to find a fence color that calms them down.

Silly, isn't it? Ridiculous, in fact. And yet, a conversation in which I've participated more than a few times in my professional career. It stems from the business side of a software development project telling the development team what they want, which should be avoided at all costs. Yes. I just said that. The business shouldn't be allowed to tell development what they want. The reasoning is fairly simple, too. They don't know what they want and even if they did, they don't have the technical vocabulary to communicate it.

What the business does know is what it needs. There's a pain point, a failing, an inefficiency, or a breakage somewhere that needs to be resolved. That's what they should be talking to you about. They need to show what the process is now, what they don't like about it, and what it should look like when the problem has been solved.

There's a subtle difference between business needs as requirements and implementation details as requirements. Subtle enough to go unnoticed sometimes. Subtle enough to even seem reasonable. It seems almost reasonable to say "The account creation form needs to validate the format of the email address." Or "I want to be able to delete accounts". But it's like two lines that aren't quite parallel. Extend them out for a long enough distance and they end up in very different places.

Let's take a look at the two examples above. Validating an email address seems reasonable. Necessary, even. After all, you don't want users accidentally putting in a bad email address, right? If we're going to have any success at all, we're going to need a regex.  Something along the lines of

bool isEmailValid = Regex.Match(emailAddress, RegexString).Success;

Problem is,writing that regex is harder than it looks. Bigger problem is that it likely doesn't solve the underlying issue. Note, I said "likely" because we don't actually know what the real issue is. All we know is that we need to validate an email address. There's no mention of why. But if the underlying issue is making sure that the user enters a valid email address, which seems reasonable, then this doesn't actually solve the problem. It's very easy to write a regex (okay- let's face it. Search for a regex and copy/paste it. C'Mon- you know you do it.) that doesn't properly validate an email address, and prohibitively expensive to write one that does.

This solution falls even shorter of the actual need if the need is to make sure that the user enters a valid address that they have access to. Which may be what the business meant. It also may not have been what they meant, but would agree this was the proper direction if they had communicated their need, thus giving the architecture team the chance to respond and ask questions. So, due to a solution disguised as a requirement, we have a solution that will likely either validate malformed email addresses or reject valid addresses and does nothing to make sure the user has access to the email address. So what, in fact, have we actually accomplished?

The second example seems pretty reasonable, too. After all, do we really want dead accounts laying around? And besides, what if there's a user that we don't want accessing their account anymore? It's not like this will be an every day thing, but just in case. The problem here isn't whether or not a solution can be implemented, it's the repercussions that are not being considered. What do we do with the order history of a deleted account? If we keep it, to what do we associate the orders? If we delete it, how do we explain the discrepancies in financial reporting? Or inventory levels vs. newly adjusted sales numbers? What if you need to process a refund? Good grief, what if you need to undelete the account? This requirement is like an early 80's Buick. As soon as you fix something you uncover two more problems.

There's no easy solution to the problem. The business side needs to be careful to communicate needs. User stories are supposed to help with this, but they only help if used properly. Here's where a good BA will come into play. A good BA can make sure that user stories aren't reduced to endless copies of "As the product owner, I want {technical solution} so that the product works properly". The three parts of the story are necessary because, when used correctly, they define a need instead of a solution. And the architect needs to ask himself, for every requirement, "What is the need behind this?" If the answer isn't immediately obvious, there's a good chance that you're dealing with a solution disguised as a requirement.


(Ed. note: If the customer requesting the fence painting is Mr. Miyagi, just do it.)

You're A Contractor

"If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands." --Douglas Adams, Dirk Gently's Holistic Detective Agency

If you're not reading Hayim Macabee's Effective Software Design blog, you probably ought to be. His Continuous Learning post is an important read and got me thinking. The article is about how important it is for software developers to never stop learning and improving their skills. Which is true and something worth reminding people about periodically. But as I read, it occurred to me that continuously learning is only half the answer.

I started out in ColdFusion professionally, back when ColdFusion was actually a profession. (Sorry, Ben) There are a myriad of reasons why ColdFusion isn't a viable career option, some fair, some born of real misconceptions, and all irrelevant, for practical purposes, to a developer who has realized that he's in a dead end specialty. The reality of the situation was that I was working in a rapidly shrinking circle and it was time to get out.

Learning a new language isn't difficult. Getting someone to hire you for it is something else altogether. My employer at the time was generally unwilling to pay for training and even less willing to put new technologies or techniques to use. I had to rely on personal projects, online learning, a ton of reading, and the one Java bootcamp I could convince my company to send me to. I eventually found myself in a position where I was competent in both C# and Java and felt I could handle a development position using either language. But with no professional experience in either, getting a recruiter- much less a hiring manager- to agree was a challenge. And so I found myself in a Joseph Heller Catch-22. I couldn't get the professional experience I needed to get out of ColdFusion without first getting out of ColdFusion.

I have a lot of people to thank for helping me break out of that career black hole. A recruiter who knew me well enough to trust me when I said "Just get me the interview. I promise you I won't embarrass you". A hiring manager who believed me when I said "Learning C# is easy and you don't have to teach me how to be a software developer." A technical lead that didn't believe me when I said that and sat for almost an hour making me prove it. And finally (Warning- blatant sappy moment) a dad that taught me to bet big on myself.

The problem I had at the time was that the way I was viewed professionally did not match what I needed it to in order to advance my career where I wanted it to go. It was +Tom Searcy at Hunt Big Sales who put the problem, and the solution, in sharp focus for me. Everyone is a contractor. With that simple phrase, he put into focus everything that had been a problem for me when I was breaking out of the ColdFusion world. Ultimately, I work for myself, you work for yourself, and it's up to you to make sure that how you are seen professionally is how you want to be seen. This isn't about "job hopping" and this isn't about always being prepared to switch companies. This is about making sure that you can direct your career the way you want to direct it.

You direct and take control of your career path by both learning what you need to know and by getting seen being the kind of professional you want to be. Neither step is useful without the other. It hasn't been a good idea to try and bluff your way into an IT career for a long, long time now. And it does little good (Trust me!) to know how to handle the position you want if no one sees you as competent. You must do both. Hayim Macabee has outlined some excellent ways of handling the former. Thankfully, there are now more ways than ever to manage the latter.

Social Media

Not so much Facebook as Google+ and Linkedin, although that might just be my personal preferences. If you want to be seen as a skilled software developer, start by looking at the information people can readily gain by looking you up. Does it show you participating in software development discussions? Are you interacting with others? Asking questions? Offering advice? Joining, or even starting, conversations?

No? Then why not? A duck doesn't have to tell people that he's a duck. He quacks.

Projects

It used to be that recruiters and "resume specialists" would tell you to leave personal projects off your resume because they were no more relevant than hobbies in the job search world. Whether or not they still do, personal projects can be made relevant to how you are viewed in the industry. We all know that developers learn by doing. Now, it's easy to show people that you're both learning and doing. Got a project you're working on? Put the code on GitHub. Tell people what you did, why you did it, and ask them to use it. Is anyone going to hire you over a project you put out on GitHub or BitBucket? No. Probably not. But if you use these tools, then you are getting seen acting as the kind of software developer you want to be. It's part of managing your professional perception.

Blog

Go start one. Now. No- wait. Finish reading mine, then go start one. Be seen publicly talking about the things you want to be known for. Then tell me about it, and I'll put it on the list of things I read. And then I'll write about the stuff I think about when I read what you have to say. Talk about the subjects on which you want to be known as an authority. Then go talk to other people on their blogs.

Software Developers have to be continuously learning. But that's half the issue. If you want to be a duck, it's time to get out in public and quack.

Projects and Icebergs

Once, I watched a class being taught to a small group of children. The subject was Aikido, an ancient martial art which utilized much inner energy, or ki. The instructor used an analogy to show internal versus external strength. ‘Ki’, he said, ‘is much like an iceberg. There is a tip, which is visible, much as external strength, which uses muscles; then there is the internal strength, which is at once much greater, and yet hidden.

…

When he had completed his explanation he asked, ‘Are there any questions?’ A small boy of perhaps four or five years raised his hand. ‘What’s an iceberg?’” --Steve Perry “Matadora”

Software development projects hinge on many things. The makeup of the development team. Resources that can be committed to the project. Management and stakeholder buy-in. However, the biggest problem I've seen is communication and the biggest communication problem I've seen is defining terms so that everyone is using a common lexicon.

Some years ago, I was part of a development project that was a miserable failure. The six month project was still in development after two years and eventually a competitor beat us to market. Looking back on it, the core problem could be distilled down to the fact that no two groups of people agreed on what any phase of the project meant. It’s not that anyone wanted to skip defining the project work or goals, or wanted to skimp on testing, or even that no one wanted to go through the time to meet to discuss project progress. The problem was that no one agreed with anyone else on how to define these aspects of a project or what should be done with them.

To some, “Testing” meant developers testing their work, and nothing else. To others, testing meant focus groups. Some thought that the project goals could be adequately communicated in a Project Charter document, others wanted to have agile-like meetings to discuss goals. And no two groups agreed on what “Finished and ready to deploy” meant. One group thought we were building an ecommerce site while another was adamant that the site should not handle payment transactions. One group defined “Deployment” as a full release that would allow all customers to begin using the site. Others defined “Deployment” as a limited release, similar to a beta test.

Even worse, there was no common definition of project roles. Sure, there was a project manager, product owners, executive stakeholders, a dev lead, and QA staff. We hit all those bullet points. The problem was that no two people agreed on what these roles meant. Because of that we had the dual problems of nobody performing certain critical tasks while stakeholders were fighting over how other tasks should be handled because multiple groups believed that the task was theirs to do.

As a result, work stagnated as developers began undoing work that one group had requested. Frustration levels ran high and developers began dragging their feet on work they didn't see a point in doing, knowing that someone else would soon have them undo the work. Testing was a mess as some groups refused to test functionality, thinking that was the developers job, and others submitted the application to a focus group and expected any feedback to be addressed. Finally, the project died when developers started leaving for other jobs.

I want to take a moment and underscore that last point. Not only did a lack of common definition of concepts cause the failure of this project, but it hindered future development projects due to development staff leaving the company.

In contrast is the project I’m on now. Development is going to take at least a year and a half and the resulting platform will have implications far beyond the current business need. We are coordinating three different business units with similar, but not identical needs. Work will be performed by four parallel development teams working separately but coordinating with each other. And this is all possible because before we even began gathering requirements we defined every project concept we could think of so that there was no misunderstanding. The definition of each project role. What "Scrum" and "Agile" meant in the context of our project. And, of course, the definition of "Project Complete".

As a result, milestones have become easier to hit. Not easy, mind you, just easier. We have agreed on what "Acceptance Criteria" and "User Story" mean so that when we do requirements gathering we all know what information is to be presented and in what form. Development milestones are easier to communicate, since we all know what to expect of code that is “Ready for sprint review”. When we talk about testing, we have agreed on what that means. Now everyone knows what has happened at each testing stage. As a result, the state of the code is clear at any given step. We have agreed on what it means to release code to production and we have a clear definition of what it means for this project to be finished.

Better yet, we have a common agreement on all project roles. Because we took the time to define “Product Owner”, we know what to expect from that role. Those responsibilities are clearly documented. As is the meaning of “Project Manager”, “Project Architect”, “Development Lead”, and “Business Analyst”. We know who does what, what to expect from whom, and to whom to look for any needed deliverable.

Of course, a common definition does not guarantee success. Agreement on terms doesn't remove the work of meeting project milestones. Because of the common lexicon, though, we can take a look at any part of the project and make a determination of whether or not it meets the definition it is supposed to. If two parties disagree on whether or not the definition has been met, we know exactly who makes the final decision. If that decision is that the definition is not properly met, we know what needs to be changed and exactly who is responsible for making the change.

Communication is one of the biggest single points of failure in a software development project. Nothing can tank a project faster than misunderstandings or people not clearly communicating their understandings and expectations. But before you can clearly communicate, everyone on the project must know what an iceberg is.

Certain Uncertainty

"There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know." --Donald Rumsfeld

--Ed. Note: Changed to link to Gene Hughson's G+ profile rather than just mention his name. Should have thought of that the first time.

+Gene Hughson , author of a blog that is shortly going to be added to my "What I Read" section, has a fascinating article on the dangers of Premature Certainty. It's quite long, but well worth reading. Worth reading a couple of times, in fact.

Right out of the gate, he gets to the meat of it:

"Premature certainty, locking in too soon to a particular quality of service metric or approach to a functional requirement can cause as many problems as requirements that are too vague. For quality of service, also known as “non-functional”, requirements, this manifests as metrics that lack a basis in reality, metrics that do not account for differing circumstances, and/or metrics that fail to align with their objective. For functional requirements, premature certainty presents as designs masquerading as requirements (specifying “how” instead of “what”) and/or contradictory requirements. For both functional and quality of service requirements, this turns what should be an aid to understanding into an impediment, as well as a source of conflict."

There are several important points here that every software architect needs to keep in mind. The temptation in a software project is to start talking about performance and quality of service- the dreaded Non-Functional Requirements, or NFRs- far too soon. It's an understandable temptation as it's near and dear to the business unit's heart. It's also a subject largely misunderstood by the business unit's heart. When Donald Knuth said "Premature optimization is the root of all evil (or at least most of it) in programming.", he was talking to programmers more than the business unit, but both sides ought to take heed of his warning.

So why is this so dangerous? Generally, isn't focusing on optimization and performance A Good Thing? Well, sure, but there's a great difference between focusing on performance and deciding on how to measure it. Especially if you decide on how to measure it before you're finished.

The problem is that NFRs are more like decorating a living room than building one. When you build a living room, you have definite dimensions you conform to.  You have building materials that you need to use, you have building codes you need to adhere to, and these are all very measurable and easily tracked. In decorating a living room, however, you have a general set guidelines to work within, but few hard and fast rules, if any. "I want the room to be light and airy" or "I want a more modern feel" are both valid sets of instructions for room designers, but it would be absurd to tell a designed "I want a minimum of 5.8 on the Light/Airy scale and am willing to settle for a 3.2 Modernness level". Yes, the designer is expected to engage the room's owner on every step of the design process, but you can't really know the final result until you see the final result. And there's certainly no scale against which to measure the final result.

This is the difference between Qualitative and Quantitative requirements, and making sure that everyone understands the difference between the two, and into which any given requirement falls, is the difference between building meaningful and meaningless requirements. Hughson references Tom Graves' Metrics for Qualitative Requirements:

To put it at perhaps its simplest, there’s a qualitative difference between quantitative-requirements and qualitative ones: and the latter cannot and must not be reduced solely to some form of quantitative metric, else the quality that makes it ‘qualitative’ will itself be lost.

And therein lies the proverbial rub. The concept of the managed project so often comes from purely quantitative worlds. Construction is an excellent example. The projects I saw at a defense contractor are also prime examples of quantitative projects- you received a set of specs and you build to the specs. NFRs didn't factor in. Software development simply isn't like that and the disconnect comes in when we try to treat software development projects as if they were purely quantitative. As architects, it often falls on us to manage this disconnect because we're often caught between the business, which often hasn't considered the difference between the two types of requirements, and the development staff, who will almost certainly understand the difference but on a more experiential level that is more difficult to communicate to someone lacking the same experiences. And as the group that is often tasked with communication between the two groups, it's of critical importance that software architects understand the difference between the two kinds of requirements and can clearly communicate the difference and its importance to the business unit.

Hughson also goes on to discuss the importance of developing functional requirements that have a level of certainly to be useful while still keeping the level of uncertainty needed to stay flexible and allow architects to do their job. Also a good read, and also necessary to keep in mind. However, as I'm in the middle of attempting to manage the development of NFRs on a current project, I very much focused on the first part and wanted to write this out as an attempt to better understand the points Hughson was making. I think it helped me and I hope it helped you, too.