chaiapodi software design

Today I completed Peopleware Productive Projects and Teams by Tom Demarco and Timothy Lister. If you go to Amazon and look at the customer reviews, you will find a five star rating. The second edition of this book was released in 1999 yet the subject matter of the book is just as relevant today as it was then. Demarco and Lister know the software industry and how the process of software development can be improved. They expose problems in the software development industry that hurt productivity and try to provide solutions to improve the process.

The two items I found to be most interesting were:

1. The project estimation section.
2. The importance of the software development work environment.

The premise of the project estimation section is Parkinson’s Law. Parkinson’s Law is the thought that project deadlines need to be set impossibly tightly to create a sense of urgency. The theory is that developers will increase the project work to meet the time allocated for the project. Demarco and Lister cite a University of South Wales study that measures programmer productivity when people in different roles are responsible for estimating the project. It compares projects that were estimated by the programmer hisself/herself, prepared by the supervisor, the programmer and the supervisor or a system analyst. Given these options the projects estimated by the Systems Analyst yielded the highest productivity. The astounding metric is that the highest productivity was achieved when a fifth option was added - no project estimate. It amazes me that in spite of the common wisdom that we must estimate the project or it will not be productive, the most productive method was when no project estimation was performed!

The other subject in the book was about the software development working environment. The summation of the section was that programmers are most productive when they have adequate space, quietness and less distractions such as phone calls and colleagues visiting with needless questions. They also work better when people doing similar work are placed in the same area. Offices with doors are much preferred to open cubicle spaces that increase distraction. I think most programmers would find these conclusions to be common sense. How many of us can say that employers are sensitive to these needs?

There are many other interesting subjects in this book and I highly recommend it to programmers and programming managers alike.

I must say I truly enjoyed the autobiography of James Dyson. He is the British designer/manufacturer of a line of fast selling, high technology vacuum cleaners.

Dyson makes a point of being different…not for the sake of being different but for the sake of his own convictions. This led him to question conventional paradigms. He embraces the individual as the underdog against the big corporations. He laments the diminution of the inventor versus the power of multinational corporations. He challenged industries that were ingrained in the psychology of culture. He aggressively improved the common wheelbarrow. He has all but conquered the vacuum cleaner market by not only inventing better technology but by making the vacuum cleaner an object of design envy. Now he is giving the common washing machine a design and engineering makeover.

This book is all about design, engineering, business, marketing, manufacturing and distribution. James Dyson seems to brilliantly do well at all of these disciplines. These skills did not come automatically for Mr. Dyson overcame many setbacks and doggedly pursued his goals on his own terms. This book chronicles his ascent to success and also shows how Mr. Dyson’s personality marks his company and his products.

I found this book to be an education and an inspiration. I would recommend it to anyone who aspires to be an entrepreneur.

This is my response to the Humanized Blog - Good Service — Bad Software

A provider of proprietary software has every incentive to keep the customer a happy user. Many times that means understanding that software users come with various skill levels. Some read the manual and scour the web for answers before calling for support. Some users just aren’t as inquisitive, have extreme time constraints or are jack of all trades generalists. These users require hand holding and since they paid for the software have an inherent right to expect a company to help them use the product otherwise they won’t be paying the subscription or buying the upgrade. They also expect that a company support person won’t give them a condescending attitude, tell them to read the manual or make other wise cracks - no matter how simplistic the support question.

I’d like to say that I am a happy user of open source and proprietary software. I appreciate the skill and brain power that is required to produce such magnificent software tools. In the proprietary world, my appreciation is largely shown through my monetary investment in the software. Some of the real ways I can pay the creators of open source software are to make donations, contribute code to the project, or promote the software through blogs, word of mouth etc. All of these forms of compensation are acceptable and valuable however they don’t form an implicit contract between the makers of the software and the user. As a user I cannot hold anyone accountable if I am not receiving the open source support that I would expect from proprietary software makers. I must depend upon the kindness, good graces and mercy of the user community and the authors of the software. I don’t have leverage in the relationship.

The maker of open source is not beholden to the user. Of course the makers of open source software understand their own software. The users of the software must largely conform to the vision and design of the software maker. If they don’t like the design they are free to change it themselves - the source is provided. If they have a question they can ask but are not guaranteed an answer.

The power in the relationship rests largely with the makers of the software. The makers do not have a vested interest in either creating user friendly software or providing user friendly support. This relationship between the maker and the user is fertile ground for user frustration.

I am left to an old adage, “there is no free lunch”. Open source is wonderfully free. The cost often comes in the form of less than desirable usability and hit or miss support.