Twitter
Here’s starting a new series that I will try and post everyday to help fellow programmers get one link everyday which points to one of the best posts that I read.
Today’s best read is Frequently Forgotten Fundamental Facts about Software Engineering by Robert L. Glass
It mentions the important fundamental facts of software engineering which people tend to forget.
It has perfectly mentioned that when the complexity of requirements increases by 10%, the complexity in code will increase by 100% and not much can be done to avoid that.
Good programmers are definitely better than mediocre programmers and we all know the pains of working with them. We all are mediocre when we start out but here the mediocre ones are who do not want to learn and grow.
Learning a new tool or technique definitely reduces programmer productivity and quality due to the learning curve as well as the unknowns while using the tool.
User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost. Nothing much to say here.
Efficiency is good design rather than good coding. I kind of agree but also mention that both good design and good coding will help increase efficiency and avoid project nightmares.
Maintenance takes up around 40-80% of the project work. This is even more true in off-shoring projects where a lot of the work is maintenance of the project after it has been initiated.
Unstable requirements will always be there. It is right to say that the requirements from the client will just multiply when the “derived” requirements come out after the requirement analysis phase.
Code reviews can help in removal of 90% of error detection and removal. And this is without testing. While error removal can’t be 100%, these two combined together can make it close. How many of the companies do seriously think about code reviews? Or even testing? A major part of the estimation is for the development cycle and testing is sent to the back bench. I need not mention code reviews as they don’t even figure in the estimation in many projects.
Reuse of code in libraries and components. While I have worked with creation of reusable libraries, I have unfortunately never created reusable components.
My favourite is the point about software estimation. Estimates done by upper management or marketing before the requirements phase and without including the people who will work on it is ridiculous. And then people wonder why the estimates were so out of bounds. Not to mention the pressure of improper estimates badly affects the quality of the project.
Related Posts:
Tags: today's read
Thanks for sharing the link..its quite useful in knowing/revising software engineering facts! However I feel we seldom apply all stated into practice.
[Reply]
Kevin Reply:
January 10th, 2010 at 3:20 am
Thanks for the comment Heena. Yes we seldom apply these in practice and perhaps this is the reason for writing this post so that we remember them.
[Reply]
“My favourite is the point about software estimation. Estimates done by upper management or marketing before the requirements phase and without including the people who will work on it is ridiculous. And then people wonder why the estimates were so out of bounds. Not to mention the pressure of improper estimates badly affects the quality of the project ”
I so much agree with this…but problem is who cares..top management doesnt care for whats right and whats wrong but how they can meet thier personal targets
[Reply]
Kevin Reply:
January 10th, 2010 at 3:22 am
We are quite familiar with such things, aren’t we
But I think there are companies who do it the right way. We just need to find them.
[Reply]
also your websites format seems to have changed…i liked the old one…just a suggestion
[Reply]
Kevin Reply:
January 10th, 2010 at 3:23 am
Thanks for the suggestion Kapil. There were a few reasons I changed the theme after much thought. First was the loading speed. This theme loads in around 1 second which is good for the readers. It is clean and under GPL
And it matches my view of this blog as a programming one.
[Reply]