Just because you have a product to show for it in the end doesn't mean you succeeded

The development process, no matter what anyone says, is a constant push and pull affair. In my experience, what I think is a good design decision is a negative decision by someone else. What I like, as a user, is brought to the table when I comment on designs and weighs heavily in my impression. For example, I think an Exit button shouldn't mean "go back to the previous screen." It should mean "Quit the program." I've lost track of the number of times where an Exit button, to someone else, means exit the page and return to where you were. I don't understand their perspective and, from the glazed looks I get when I talk about renaming "Exit" with "Cancel" or even "Previous," I often get blank stares.

This whole idea of tug of war in the development process is especially evident in the following e-mail I received from a member of one of the lists I'm on, who will remain anonymous. Bits of what this person wrote sound familiar. I have some comments at the end so read the whole thing:

---

Subject: Status Update

I am really tired of all this BS. I mean, seriously. We keep on chasing our tail and it's really pathetic. In our last demo, all I heard were complaints about colors. It was announced that we couldn't sell this without a change in the colors. No one liked them the way they are.

I distributed screenshots of the system we were discussing on Monday.

We needed those back on Thursday in order to make our Monday deadline. After a couple emails to remind people about our need for the screens in order to proceed, I finally got a call around 2pm on Friday (Delay #1), asking me to clarify again what I wanted.

I said the screens were there so "quick changes" to the forms could be marked. I said that all we wanted were color changes, wording changes, field positioning/order changes, and anything else simple like that, but no large functionality changes if we were to be able to get this done. We used screenshots for a couple reasons. One reason was to document suggestions and the other was to allow independent work and from the comments received, make a final decision regarding colors.

This approach backfired. Shortly after that call, a member of the Team was pulled from working on his tasks - which are critical to getting test data so we can verify our calculations are correct - and told to meet to talk about the screens. Pulling him from working on his tasks means a delay (Delay #2)

As of Friday at 5:10 pm I had not received a single screen. And the revisions are due on Monday. I went over to the meeting they were having. They were arguing about functionality - nothing to do with colors - and had not yet finished talking about it. I was able to extract about 9 screenshots (1/2 of the total) from their hands with a lot of comments on them.

They told me that for the rest, I would have to wait until they were done meeting on Saturday. (Delay #3) Yes, Saturday.

A meeting among the same people was held on Saturday. It was scheduled for 8 AM. I know for a fact that two of the attendees - including the member of our team - were there for the meeting at 7:45 for the meeting. However, others came @ 9:30 (Delay #4)

Finally, I got the screen shots back around 2 on Saturday - 2 days late.

Here is what they did:

• First, they didn't do the assignment right. There isn't a single color change specified.
  
• Some screens are being reverted back to the ones the team had done back months ago that were rejected.
  
• Two screens have a big X through them and the words "Don't Need!"
  
• There's some notes about new functionality that must be added. That's *not* a color change!

But far and away the two that really got me were:

1. These are major changes that they want. The database needs to be changed. In the same breath that I take heat for not meeting our deadlines, we are given changes that will only add more time. I don't know if anyone really gets this: if my deadline is Thursday, and I get the information I need to do my job on Saturday, the deadline has to be extended. It still takes the same amount of time to do my work as it would if the Thursday deadline was met!
   
• The program can be released and will work, but doesn't need most of these changes. They are ones that are not critical to our users using the product! BUT they are being made to be critical. I do think these changes absolutely should be done at some point - I agree with them. But why now if our collective goal is to release a product? Does anyone really believe version 1 of these systems will be perfect? There is no reason to think these new systems will be perfect with version 1.0. We haven't even put it through the validation team ringer yet. They will have changes.
• On a side note, I really have a problem with the way this project has been going. I asked for specs and documentation as a requirement to getting this project done. I have asked repeatedly to have this information. Whenever I mention the word specs or documentation, it seems to be mistaken for a curse word. It's not. They are essential to having a marketable product!

Last week in a meeting, when we discussed this for the umpteenth time I again got the answer, "You asked for specs and I gave you a member of the team that knows the system."

Is this working? The answer is "NO!" This approach to software development is based upon a single perception of the functionality - yet, there's arguments about what functionality needs to be included in these systems?

You know thte biggest kicker? After years of designing and coding for a PC-based product, I'm asked to make it browser-based.

We went through this years ago. No one liked browser-based. There's no way to make a browser-based app act exactly like a PC-based app out-of-the-box without extensive coding. Coding takes time and we're already past our mandated deadline. So, heck, let's just add more things to do before we get these systems to market! There are radically different design considerations, not to mention functional differences between a PC app and a web app? When developers were sent to training, they had a class on PC apps. Who is going to rewrite all this stuff to be a web app? Are we hiring people I don't know about?

This brings up many, many issues:

• Are we really saying to scrap the UI that was being argued about in the Friday and Sat meetings and redesign all of this as a web app?
• Why is this being changed now? Why at the END of this project!?!?
  
• Why didn't we train people to do web apps if that's what we wanted to do?
  
• Why have we not received clearly defined goals and decisions on direction?

And you know, honestly, I'm all for a web product. That's fine. I'm all for the suggested changes too. In fact, I'd be more than happy to scrap the entire front-end and all the code I've spent nights and weekends writing to make development easier if the final decision is that we want a web product.

I'll even do it all without a single complaint. But this nonsense of changing priorities, pulling team members from their tasks, and making these late-in-the-game decisions is not helping us at all. It is making the success of the project in jeopardy.

When such prolific indecisiveness has plagued this project since the start, I'm not seeing any signs of it letting up. I mentioned the other day that if we don't actually plan things, we would fail. Isn't it obvious yet? When I said that lack of planning and documentation would cause us to fail, I meant it to be understood that failure can come in many forms. Sure, it could mean the project doesn't get completed, which would be the most obvious failure, but it can also mean that we miss our time-to-market, we spend too much time on some aspects and end up spending more money for developers to program those aspects than we ever should have. Just because you have a product to show for it in the end doesn't mean you succeeded.

---

My jaw hit the floor many times while reading that e-mail. I have a few questions:

1. Will there ever be a version 1.0 in the market of this product?
2. How long will testing this product in the validation department take?
3. Will the users like it?
4. How is a person a replacement for specs? What if that person leaves or is, God forbid, hit by a bus?

If I get any other info re: this person's situation, I'll be sure to pass it along.