Why do most diets not work? What does this have to do with software development?

Why do most diets not work and what does this have to do with software development? It turns out that diets don’t fail, but people fail to stick with the diet. The secret to losing weight is a pretty simple concept and hard to do. The secret, of course, is to eat less food, drink less booze, and exercise. The bottom line is if you burn more calories than you take in you will lose weight.

Most software process improvements don’t actually fail. People fail to stick with the process improvement just like most people fail to stick with a diet. When you think about it a diet is a process improvement plan too.

To stick with any process improvement takes a tremendous amount of discipline. It takes discipline to lose weight and it takes discipline to develop good software too. This little snack here or there adds up to a few extra pounds just like this little short cut here and there adds up crappie software.

Advertisements
Published in: on November 5, 2009 at 17:20  Leave a Comment  
Tags: ,

Ideas on Productivity

I stumbled upon a very good blog related to productivity and I thought I would share it.

http://www.productivity501.com

Published in: on October 30, 2009 at 09:11  Leave a Comment  
Tags: ,

What is the average cost to develop software — It depends

I get asked the question, “What is the average cost of develop software?” all the time.  The answer it depends.

1.  When people ask the average what they are asking is what is the average unit cost of software.  This is a similar question to what is the average cost per square foot of construction.  I use function points, so the question becomes what is the average cost per function point to develop software.    The average dollars per function point is one way to determine the average dollars per unit of software developed.

2. The average cost per unit of software developed depends on several factors.

2a.  The type of business the software supports.  The unit cost of software is going to be different for insurance industry and the aerospace industry.  The same is true with construction.  The average cost per square foot  to build a mission control building for NASA is not going to be the same as the cost per square foot to build an insurance office building.

2b.  Location, Location, Location.  Like real estate the cost per unit of software is going to depend on where it is built.  If the software is built with cheap labor (the main input), then the cost will be less.  Of course it depends if the cheap labor is of equal productivity.  If the cheap labor is half the cost and half as good, then you really do not gain anything from using cheap labor.

2c. Duration.  The duration impacts cost too.  Not only development costs but maintenance costs.  If the the software has to be developed as soon as possible it is going to be expensive per unit.

Actually there are about 50 other factors that impact cost, but these are three big ones.

Read more at Reboot! Rethinking and Restarting Software Development.

Stone Cold Coder meets Diva Developer!

Cheech and Chong, a 1970’s comic act, portrayed themselves in one of their skits as Siamese twins that were not identical.  They were paternal twins physically connected at the hip.  Of course this was impossible, absurd and a very laughable idea.  Whenever I hear about pair programming I can’t help but think about Cheech and Chong and the absurdity of the idea.    It is like asking two teenagers to share a mobile phone.   It ain’t going to work folks.  It is absurd and laughable.

The idea is that one programmer writes code and the other programmer stands over his or her shoulder and watches for mistakes. When the first programmer gets tired they switch positions.  I think they are suppose to touch hands like professional wrestlers do in a a tag team wrestling match.  How cool would it be to called something like Stone Cold Coder or Diva Developer.  You could go to work dressed in costume.  Instead of programming sessions you could have smack down coding sessions.

You don’t have to implement Agile to try out  the idea of pair programming.  I would suggest  trying pair writing.  Have one person start to type and have another person stand over them and correct them as they go.    This is an awesome idea! I am curious to see how long this process would last.  How about pair cooking?  You have one person cook and another person correct them as they go – nice.  How about pair driving?  You could have one person sit in the backseat and correct the driver.  I think that is called back seat driving.  Sorry pair programming is a joke of an idea and absurd.

——————————————————————————-

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Reboot! Rethinking and Restarting Software Development.

Agile Methods and Other Fair Tales

If you are having a hard time coming up with a pseudo name for your pair programming team check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

Professional Wrestling –http://www.wwe.com/

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

The great exalted software guru measures time in bytes

The great exalted software guru measures time by the size of the USB drive I give to him. I brought with me a 16 GB USB drive able to fit on a key chain to give to the guru. I laid the new 16GB drive at his feet and the guru picked it up and examined it closely.

He said, “It has been a long time since you last visited.”

I asked, “How long has it been?”

The guru replied, “It has been 15 gigabytes ago.”

Yes, the guru was right it had been a long time. The guru said, “You first visited me 16 gigabytes ago.”

I said, “How can it be that I gave you a 16 gigabyte USB drive today and I have visited you many times before.”

The guru smiled and said, “Time begins now not yesterday.”

I thought I am going to need a bit more explanation than that and I started to speak and say, “Exalted software guru…”.

The guru held up his hand and I stopped. The guru continued and said, “In software the first day of learning starts today not yesterday.” I started to speak again and the guru held up his hand to stop me. The guru said, “skills that were useful yesterday are not useful today. Those skills you develop today will not be useful tomorrow. This is why software professionals need to learn something new every day.”

He reached under his rob and scratched himself. I felt a bit uncomfortable not knowing how to respond and then he pulled out a 5 ¼ floppy disk.

I thought, “640KB.”

He said, “no 720KB.”

I said, “16GB minus 720KB is really just about 16GB, so the 720KB is insignificant.”

 The guru smiled and said, “YES!, what you learned in the past may not be useful today or tomorrow.”

I asked, “if skills that I learn today are not useful tomorrow then why learn them today?”

The great exalted one held up his hand and said, “Why do you keep trying to interrupt me?” I apologized and he continued and said, “you need skills today and you need to learn tomorrow’s skills today too.” I nodded because I started to understand.

Just like he always does the guru picked up his new 16GB USB drive and walked back into his cave. He waved and said, “I will see you in a few terabytes.” It was his way of saying I will see you soon.

 I walked down the hill and thought what I had learned today. I need to learn something new every day about tomorrow. I can’t live off of the technical skills I learned in the past. Then I thought, “I wonder where I can buy a 1 terabyte USB drive.”

More from the guru…

https://davidlongstreet.wordpress.com/2009/04/27/the-software-guru-speaks-again/

Pay no attention to the little man behind the curtain!

The little dog Toto pulls back the curtain and exposes the Wizard.    In this most embarrassing moment the Wizard thunders out, “pay no attention to the little man behind the curtain.”  Well, there are many IT organizations and IT “professionals” saying the same thing these days.  Too many IT professionals are Wizards pretending to be something they are not.  They manipulate knobs and dials creating a lot of smoke and noise.  They give the appearance what they are doing is really complex and sometimes even frightening.   When challenged they will speak in techno talk in hopes they will not be challenged.

 Over the years, I have pulled back a lot of IT curtains and heard over and over again “pay not attention to the little man behind the curtain.”

Watch out for fling monkeys too!

Read more at Reboot! Rethink and Restarting Software Development

Technical Support Cheat Sheet – Cartoon

A friend of mine sent me this cartoon that outlines the steps necessary to solve most technical problem. The great thing about this cartoon is that helps people learn the steps necessary to solve problems instead of providing an answer.

Technical Support Cheat Sheet

Technical Support Cheat Sheet

Read  more at Reboot! Rethinking and Restarting Software Development

Published in: on August 24, 2009 at 11:20  Comments (2)  
Tags: , ,

Is software an art form?

If software was truly an art form, then the same adjectives used to describe art would be used to describe software.   I often software developers ask, “What three words best describe your software applications.”    Seldom do I hear words like, beautiful, elegant, sophisticated or graceful.   On the other hand,  I have had many  say, “Alt, Control, Delete.”

Published in: on August 5, 2009 at 06:56  Comments (1)  
Tags: ,

IT the toilet that never stops flushing

I was consulting for a large international firm and one of the executives on the business side made the comment that, “IT is the Toilet that never stops Flushing.” To often this is an accurate phrase to describe how money is spent in IT. Most of us have had a running toilet in our bathrooms and it can be very annoying. In the end a running toilet is just money down the drain and too often spending money on IT is money down the toilet too.

Over the past 20 years a lot of IT spending was done without careful cost benefit analysis.  Too many projects were undertaken because there was a desire to move to the latest and greatest technology.  The current recession is causing IT to really justify its spending.   The business is forcing IT to wiggle the handle to see if they can’t stop the water from running.

Even though the current fade de jour is build as you go or ad hoc software development it is an expensive proposition.  Those IT organizations that embrace, study, and learn  the core business are the same organizations with the highest productivity rates, best quality and lowest costs per unit.

Read more at Reboot! Rethinking and Restarting Software Development

TPS Reports and Cover Sheets

Too often people are asked to record their time or report data and are clueless the reason.   They start thinking, “what’s the

initech

initech

point?”  They think of the ole, “IniTech – T.P.S. report” from the movie Office Space (TPS Time Sheets & Cover Sheet).

When people see how the data is being used, the value, “what’s in it for me”, then they are more likely to input data correctly and sometimes enthusiastically.

When I develop metrics for an organization, I have to rely on the quality of time sheets. Often people tell me the time sheet data is no good. If I am building estimating models based upon past data and the data is no good, then, the estimating model is going to be wrong too! I have to make a lot of adjustments to the historical data. Knowing how people spend their time on past projects is an invaluable management tool when planning for future projects. When projects are planned properly there is less chaos and often less overtime. Overtime is often the result of poor planning and poor estimating.

Read more at Reboot! Rethinking and Restating Software Development.

TPS Initech Time Sheets

Published in: on July 20, 2009 at 23:01  Comments (1)  
Tags: ,