This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Thursday, April 27, 2006

Why do people spend so much time criticizing each other?

In this blog and others in the software community we try to learn from our experiences by expressing them in writing for others to read.

I have a pragmatic approach to software development. I try new ideas, give them a fair shot if I believe they could work and then assess if they did work as expected. Blogs are important because they give me that extra set of ideas I would not easily come across otherwise.

I'm also not hung up on being perfect, my job is to get profitable software out that makes the users so happy they want to come back and buy more software. I also understand that the skills that we develop and learn in doing so are important, so important that I would like to contribute to the community by describing some of the skills or (more precisely) techniques that I learn in my job.

Unfortunately this attitude is not shared by all in the software development profession.

It is sad for me as a member of this community to see and hear so many people criticizing each other without really trying to prove their ideas in practice or even really understanding what each other are trying to really say.

I've often heard/read criticism from one person that had been successful against another that had been equally successful. Stop it guys. If you both are successful in software development, share your experiences and stop criticizing each other.

We need a positive spiral of learning in the community, not more infighting for self-importance and conference gigs.

Dear gurus of the software industry: we listen to you all, but we need positive ideas not mean criticism just because people don't agree with you.

at 23:33 | 0 comments
RSS link

Bookmark and Share

Sunday, April 16, 2006

99 rules too many...

Boy do the NASA project managers have it hard. Not only are in they under pressure from government and private entrepreneurs (remember the X-prize?) now they also have to
memorize 100 rules!

That's what I would say 99-rules too many!

I have only one rule:
1- Use your head!

OK, ok, that's a simplistic way to describe it, but that's really what project management is all about, using one's intelligence to plan a project and solve all those unpredictable situations you will be faced with.

There's also a plus: if you apply my rule #1 you are surely going to come up with your own, personal, custom-made 100 rules! And you don't need to trust NASA, after all they have failed projects - you don't want that! (or do you...) ;)

at 01:07 | 0 comments
RSS link

Bookmark and Share

On Agile management

This week I came across two interesting articles about agile management (related to software of course ;).

One is from Joel Spolsky, it's called "
The Development Abstraction Layer" and talks about the need for good management to enable the work of productive and creative software developers.

The second article comes from CNN and is about an Indian manager that embodies a new way to manage.

Both these articles talk about the need to have a new way to look at management in a software company. Management is a key enabler for work to be productive. Management needs to understand that role. The era of counting coins and seeing $-signs every time a contract was signed is over.

Today's users expect much more from the software they buy then just flawless functionality. They expect an experience that makes their time worthwhile. Companies like Microsoft that sell mostly disconnected products (ever tried to edit a small newspaper and a blog with Microsoft tools or have you ever used MSN?) can sell many products but not in the long run.

People expect also passion in the products they use. Not just a mindless collection of features requested by everybody and their dog. Design will become more and more important and design, good design, only happens if your employees are motivated, and if your employees are motivated they will be the first to motivate your customers.

These two articles touch the surface of an important transformation in the software business but there's a lot more to learn.

One book that also discusses agile management is "Maverick!" by Ricardo Semler, a must read if you are interested in turning your company around.

at 00:37 | 0 comments
RSS link

Bookmark and Share

Saturday, April 15, 2006

Writing the right documents

Here at our company we hear everyday amazing and interesting things. Once someone said "Let's move these documents to wiki" - they were talking about a few of the dozen or more documents in one particular project.

When asked why, they replied: "Because we want to 'maintain' these documents".

Hum... If that is the case why keep any documents outside wiki then? And why do you need documents that you do not plan to maintain?
(NOTE: documents that need to be delivered to customers are a totally different category, I'm talking here about project-related documents that are used only inside our company)

Why, in general, do we write documents in software development projects that we don't want to maintain? Here's a few guesses:
- Because management says it should be done...
- Because Rational Unified Process (RUP) says so!
- Because everybody does it!
- Because we've always written them!
- Because the person who writes them would be out of a job if we did not write them!

We seldom hear this:
- Because it adds value to our customers!

Why is it so? My guess is: because those documents that add value to our customers require 'maintenance'. Those are documents we want to keep always up to date as they will go to customers. Or customers expect those documents to be kept up to date for any other reason. Here is the key: the documents you don't update are normally documents that add no value to your customers. So, once you write them then you are done with that document and you don't need to touch it again.

There are valid reasons for writing documents that don't get updated. One example is that writing helps clarify ideas, and the process of writing a document may help you structure your thoughts and develop your original idea to a certain point.

One example I often like to quote is the Vision document. I always keep the Vision documents I write 2 pages-long, and I make myself write that document for every major project.

By writing that document at the beginning of the project (even if I don't update it later) I make it clear to myself and the project team what this project is all about. Keeping to a maximum length of 2 pages also makes me clarify and synthesize my ideas (or the group's ideas) at the same time making me cut down on the superfluous things for that product/project.

I don't update that document later, but the actual process of writing the document helps me in my work. In my book that's a document worth writing!

In other projects, however, that's not what I see as the role of documents. People still write documents thinking that the mere fact of writing that document, or even worse, the fact that document exists will make their project a success. To add to the problems with this, many people write documents that are not supposed to add any value anywhere in the project, they just do it because the process says so!

To avoid writing documents that you don't really need, ask yourself these questions:
1- To whom am I writing this document? Would it be better if I talk to them ?
2- Would it be cheaper to explain my ideas to the target audience? (some documents are written for 5 hours to be read by 2 people, it would be much cheaper to just talk to those people and maintain a good communication channel then spending 5 hours writing that document!)
3- Am I working in an environment where people don't trust me? (if you are you have two options: a) cover your ass by writing a document and getting it signed off, b) quit and find a better job. I would go with the second option).

Consider also the required quality for the document you are writing:
1- How much time do you think a person has to read this document? (probably they have half the time you think: just ask them. 5 minutes: 1 page, 10-15 minutes: 2 pages, more than half-hour: 5-10 pages - please don't make it longer than 10 pages...)
2- How accurate does it need to be? (not at all: don't review it!; somewhat: write it and explain it to someone who does not know about the content but could tell you if it is accurate in their view; very accurate: are you sure you have enough money and time to do this?)

Writing good quality documents is difficult, but more difficult is to write the right documents. Think twice before you decide to write one.

at 12:00 | 0 comments
RSS link

Bookmark and Share

 
(c) All rights reserved