Enough with what doesn't work?

So? are you frustrated now that all I seem to be doing is railing on all the things that don't work, which is a lot easier than saying what does work? Ok, fair enough. What does work.

This is going to sound silly but here it is. What does work is:
communication, trust, collaboration, and mutually beneficial motivation.

It sounds silly, but be honest, go through this list and tell me if everyone on the project team would say you have those 4 things?

Communication - I know, everyone says that's the most important thing, but in software development, it's not the same as building a skyscraper or a submarine. How so? it's not because they aren't as complex or as big, though that can be part of it. The issue is more that you can't and don't know what you are going to have when you start. There is an evolutionary process that stretches the human mind and creativity and business process, and solutions mindset when you develop software. What you have in the end of a successful project is never what you started out to build, specifically. Abstractly, sure. You want a website, you get a website. But of the 12 things you said you had to have, during the course of the project only 7 remain and you've picked another 7 that were not on the list because you've learned. You aren't dumb, as a client, you just didn't see it all unfold until it started unfolding, at that point it made sense. So the type of communication that you need is not static at all, it's dynamic. And it has these key components:

1) Task/deliverable bounded - don't worry about talking about your philosophy of how to hep users, or what the organization should be doing in 2 years, worry about what the business rules are for the 4th screen, what are the options, what are the impacts and who is going to implement them.

2)Timely and direct - avoid the urge to put things off - action items, meetings, email messages can be a form of procrastination. Just get it done. You need an answer, don't write down that you need an answer, get on the phone or walk down the hall and get an answer. The email that you write should immortalize the discussion so no one forgets and so that others can be benefiting from the knowledge of your discussion. It's all about how quickly you can get enough information to make a decision and move forward, 5 minutes time on task might take 2 weeks if you don't just get in someone's face and ask the question.

3)Solutions oriented, do not own the issue or problem and don't make anyone else do that either. Seek a common solution together. In order to do that, remember, you have to correctly identify the problem and accept that the problem exists. That sounds a lot easier than you think. I bet you can think of issues that are driving you nuts that others would deny are problems at all. Why? probably because they own the problem and therefore are in denial. Do not meet to meet, meet to work out a deliverable, walk through the deliverable during the meeting, when you are done with the meeting, you have done some of the work, rather than havin a huge list of t0-dos which you are not always going to finish.

4) Communications are part of the teams collective consciousnesses. Don't keep the conclusion of the discussion to yourself, share it with everyone who might benefit from it so that you essentially can put the conclusion in the hall of fame and move on to the next discussion. Otherwise the audience is only partially represented and the value of the communication is dramatically reduced.

5) Focused and appropriately audienced (ha I just made that word up, do you like it?) - Do not have discourses with people who have no authority, input, expertise or ability to influence either before or after the discussion. If you start a conversation, on any media, you know should know what you expect to get out of the discussion, or you should not have started.

Common Misconception

Have you ever heard this: We don't have time to document our code? We just need more time. I know I'm supposed to be doing a project management plan, but I just don't have the time. If you want me to do that the entire project is going to take a lot longer.

See here is the reality. People don't do things if they don't pay off, they may start but they quickly stop if it doesn't pay off. On the otherhand, if things work they will keep doing them.

You will find I like to explain things with analogies because human beings understand object models and we actually have a lot of complex object models in our head that have taken long time to develop and it turns out that most object models are more the same than different. I recognize that they aren't 100% the same, but hopefully enough to get the point across.

Ok so here's my first analogy. I really want to make it with that woman. But I don't have time to get a condom, so I'll skip it. Well now, what if you end up paying the price for that time savings, either in becoming a potential father or getting or giving a disease. Is it a pain to do? yes, but it pays off, so you do it.

Is software documentation like a prophylacitic for your system? could be, if it's the right kind of documentation. OK maybe I better stop with that analogy or it will get people really on my case. But hopefully the point is made. When things pay off, however inconvenient, you do them, if they don't pay off you find excuses that usually stick and you don't do them.

Industry Standard Solutions - MORE RIGOR

EVM, CMMI, RUP.



Have you looked into these things? OK they came from manufacturing, ISO 9000 (is that the right one), and all that. So you plan what you do, you check it all the time, you replan, train, test, test the tests, report, look at risks, issues, and more more more process. How many of these actually contribute to writing more code that helps the users? or are they more of CYA.



Hey, we have 4 inches of documentation. But does the system work? are the users happy? no idea but man look at our documentation!



Here is IBM's concept.



http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html



Note number 5, use webshpere! hmmmm.

Other's and their conclusions

So in order to see if I'm crazy, I am looking to see if people agree with me or if there are other ideas.

It's pretty amazing. These conclusions are 100% missing the boat, they didn't mention anything about methodologyn thier top 10 lists.

This one is a riot!


Look at the solutions:
Add more more time, add more resources
Threaten to litigate! NICE

And what about this Gem:

3. As Glass explains, always consider Hofstader’s Law. This law states that software development always takes longer than you think, even when you consider Hofstader’s Law.

What a cop out. It's harder than you think, even if you know it's harder than you think? OH please! Why not just say, Waaaaah!

Ever Wonder (in an Andy Rooney voice)

So? have you ever wondered why most software development projects are basically complete failures and yet people continue to work in them and clients keep paying for them and nothing really changes? Well if you do, you aren't alone.

The answer isn't what people generally want to say. Typically they want to say things like:

• The scope keeps changing
• The clients are stupid
• Developers write sloppy code
• We don't have enough testers
• We never have enough time to write all the documentation
• My manager is an idiot
• We don't have good development processes
• The client doesn't even know what they want

The truth (IMHO) is not any of those things. The truth is actually something that can be fixed. However, that doesn't mean it's simple or that people can get it done quickly.

Part of the problem is that Software Development usually involves some very smart people. Smart people have are good in many ways, and they are also bad in many ways. Some of the bad ways are:

• They are too proud, they have pride of authorship and they want it to be done their way
• They don't always take direction very well
• Once they have learned things, they typically go back to them over and over, even if they really don't apply (see the Queeg Quart of Strawberries Syndrome which I will explain later)
• Some smart people don't remember that it's not what you know but what you do with what you know - it's about acting smart, not being smart.

So in many ways, having smart people working on a Software Development Project is actually not such a great thing.

Thus it begins

After 20 years of developing software, I need a place to put my thoughts, what works, what doesn't and why. This is that place. With any luck others will join, comment, confirm or deny and eventually people will understand why most software projects are completely messed up.