Always working estimation techniques - re-estimation

  • (Fact 8.) One of the two most common causes of runaway projects is poor estimation.

  • (Fact 9.) Software estimation usually occurs at the wrong time. - at the beginning of project.

  • (Fact 11.) Software estimates are rarely corrected as the project proceeds.

Consequence: Re-estimate your issues!

This an an extremely powerful technique to control estimation and schedule plan.

Take your time (at 1/3 of the estimates project schedule) and review all task/story remaining and adjust estimates based on experiences. At that time you have gained a solid experience in domain, technology so your estimate will be much more reliable.

What is more: it is absolutely independent from any other estimation technique. It can be applied on any kind of estimates: ideal man day, story points, confidential ranges etc.

You might be afraid of spending huge amount of time on estimating again. But it is wrong. The first estimation takes long but if you analyze how you are spending your time you must recognize a certain pattern: it takes more to understand the issue then doing the estimate.

But the second time you do not need to understand the domain. You can focus on estimation only.

Based on my experience it takes fraction of time comparing to the time spent on the first estimate.

Several months of work can be reviewed/re-estimated in 1 hour with team. It means it can be really frequent. My experience is that after the first or second re-estimation no more re-estimation is needed because the domain become clear the estimations are not reducing risk significantly.

Dec 15, 2014

Facts and Fallacies of Software Engineering


I have ambivalent feeling related to this book.

First time I have read I thought that this book is obvious. (At that time I was reading many of the book it is referring to).

The second occasion I have realized that from an objective point of view it is a great book.

Reading the third time (after partially reading "How to measure anything") I had to admit how important the book is. It is full of evidences, statistical facts, studies to prove how valuable each of the statement it has.

Must read!


  1. The most important factor in software work is the quality of the programmers.

  2. The best programmers are up to 28 times better than the worst programmers.

  3. Adding people to a late project makes it later.

  4. The working environment has a profound impact on productivity and quality.

Tools and Techniques

  1. Hype (about tools and technology) is a plague on the house of software.

  2. New tools and techniques cause an initial loss of productivity / quality.

  3. Software developers talk a lot about tools, but seldom use them.


  1. One of the two most common causes of runaway projects is poor estimation.

  2. Software estimation usually occurs at the wrong time.

  3. Software estimation is usually done by the wrong people.

  4. Software estimates are rarely corrected as the project proceeds.

  5. It is not surprising that software estimates are bad. But we live and die by them anyway!

  6. There is a disconnect between software management and their programmers.

  7. The answer to a feasibility study is almost always “yes”.


  1. Reuse-in-the-small is a solved problem.

  2. Reuse-in-the-large remains a mostly unsolved problem.

  3. Reuse-in-the-large works best in families of related systems.

  4. Reusable components are three times as hard to build and should be tried out in three different settings.

  5. Modification of reused code is particularly error-prone.

  6. Design pattern reuse is one solution to the problems of code reuse.


  1. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.

  2. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.


  1. One of the two most common causes of runaway projects is unstable requirements.

  2. Requirements errors are the most expensive to fix during production.

  3. Missing requirements are the hardest requirements errors to correct.


  1. Explicit requirements ‘explode’ as implicit requirements for a solution evolve.

  2. There is seldom one best design solution to a software problem.

  3. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.


  1. Designer ‘primitives’ rarely match programmer ‘primitives’.

  2. COBOL is a very bad language, but all the others are so much worse.

Error removal

  1. Error removal is the most time-consuming phase of the lifecycle.


  1. Software is usually tested at best to the 55 to 60 percent coverage level.

  2. One hundred percent test coverage is still far from enough.

  3. Test tools are essential, but rarely used.

  4. Test automation rarely is. Most testing activities cannot be automated.

  5. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

  1. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.

  2. Rigorous inspections should not replace testing.

  3. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.

  4. Reviews are both technical and sociological, and both factors must be accommodated.


  1. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.

  2. Enhancements represent roughly 60 percent of maintenance costs.

  3. Maintenance is a solution– not a problem.

  4. Understanding the existing product is the most difficult maintenance task.

  5. Better methods lead to more maintenance, not less.


  1. Quality is a collection of attributes.

  2. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.


  1. There are errors that most programmers tend to make.

  2. Errors tend to cluster.

  3. There is no single best approach to software error removal.

  4. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.


  1. Efficiency stems more from good design than good coding.

  2. High-order language code can be about 90 percent as efficient as comparable assembler code.

  3. There are tradeoffs between optimizing for time and optimizing for space.


  1. Many researchers advocate rather than investigate.

And the list of fallacies:


  1. You can’t manage what you can’t measure.

  2. You can manage quality into a software product.


  1. Programming can and should be egoless.

Tools and Techniques

  1. Tools and techniques: one size fits all.

  2. Software needs more methodologies.


  1. To estimate cost and schedule, first estimate lines of code.


  1. Random test input is a good way to optimize testing.


  1. “Given enough eyeballs, all bugs are shallow”.


  1. The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data.


  1. You teach people how to program by showing them how to write programs.

Some reviews:

Dec 14, 2014

I give a shit on story points

You can see story point more and more famous as a kind of estimation (and scheduling technique). It intends to simplify estimation and scheduling but in practice it makes life more and more difficult.

What is the story point?

Let’s see some definitions:

“Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.” – agilefaq

“A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure which describes how heavy, far, big or complex something is.” – Explaining Story Points to Management (Otto: Soooo bad…., see later, mixing up SP and velocity and their relationship…)

” The number of use case points in a project is a function of the following:

  • the number and complexity of the use cases in the system
  • the number and complexity of the actors on the system
  • various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases
  • the environment in which the project will be developed (such as the language, the team’s motivation, and so on) “ – Estimating With Use Case Points (Otto: Quite a lot of not so related aspect of development…)

And many many more….

It has a huge literature. One of the always quoted reference is Mike Cohn’s Agile estimating and planning. It is not only about story point but it is clear that Cohn preferes story point more. (On the other hand the book itself is great, a must read.) (De facto “main reference point” about story points.)

In out “everyday” it come up in the context of Scrum I have participated in several Scrum introduction and I have indirect (but close enough to be reliable) information from other. Without any exception it introduced the usage of story points.

BUT: Scrum is not about story points. Not at all. What is more! Not even talking about estimation. Nothing. When I am saying Scrum I am talking about the Scrum as it is. Of course when you are talking about Scrum it is always the original Scrum PLUS many-many additional tools and techniques (including story points).

Once I had a talk with some manager using Scrum in his organization. He told me that one of their current challenge (using Scrum for many years and still having this problem. hmmm…. - on the other hand they have introduced a very agile process which is great) is to make business people understanding the concept of story points. I think it is a mistake to explain it to a businessman who is interested in time and schedule…

In one of his presentation Dan North highlighted why story point is insane (around 24:40 - not exact transcript):

  • (businessman) How much will it cost and when can I have it?
  • (agile guy) We don’t know. We are agile.
  • What?… How much will it cost and when can I have it? These are not hard questions.
  • OK. We have done some work and we think that it gonna be 295 stories..
  • What?…
  • And about 1000 story points.
  • What is the story point?
  • We don’t know yet.
  • You are absolutely kidding me.
  • We gonna run for few weeks and we gonna burn up and burn down and the velocity and hablalal…
  • Stop! Stop right now and get out of my building.

(Humorous with lots of truth!)

As I see (and it cause me many problem when dealing with story points). It tries to mix up many unrelated estimation characteristics into one single number:

As these risks are so independent from each other you have to use different strategies and techniques to manage them. But if you are hiding these aspect behind a single figure you do not even have a chance.

Plus it has so many other weakness:

So if story points has so many issues why are we using it?

Instead of story points

Instead of story points you should use calendar based estimates with proper risk management and (semi-)automatic estimation adjustment.

But how? It is a subject of another article (later).

Nov 25, 2014

Mike Cohn: Agile Estimating and Planning

cover agile estimating and planning

Original: 2009 on

– en –

Must read book.

I had two sources which made me interested in the book. The first is a presentation in Youtube. The second is a book about Scrum. Both of sources was persuasive enough to read the book. So I did. An I was not disappointed.

Excellent book.

There are lots of subject and experience described which is good not to expereince yourself. You could nmake a much faster Scrum introduction if you know what is described in the book.


The book

– hu –


Két forrás keltette fel a kiváncsiságomat ez iránt a könyv iránt. Az egyik egy előadás, amit a Youtube-on láttam. És egy a Scrum-ról szóló könyvel kapcsolatban. Mind a két forrás meggyőző volt. Így hát neki estem. És nem csalódtam. Kiválló könyv. Sok olyan témával és tapasztalattal, amit jobb, ha az ember nem saját maga tapasztal ki, ha nem muszály. Sokkal hamarabb lehet bevezetni az agile fejlesztési módzsereket, ha tisztában vagyunk a könyvben leírtakkal.

Teljesen biztos vagyok abban, hogy még párszor el fogom olvasni az idén.


Maga a könyv

Nov 23, 2014

Thinking about week 44

Why I hate hibernate

It is series of articles highlighting difficult or even impossible to resolve issues with Hibernate (in Grails). And his is right.

I summarize my experience like this:

For simple things Hibernate is very good but all other mapping tools are good too. Bus as soon as you reach a certain level you have to lick Hibernate’s ass. It is not serving you anymore but you are serving it.

Oct 30, 2014

Super cool :) - Ship sizes across the univers

Oct 29, 2014

Thinking about - week 42

The Three Essential Keys to Work Motivation

there are three factors for work motivation:

  1. Autonomy: the control you have over your work. The more you can control what to do and when to do it, the more motivated you are.
  2. Mastery: the sense of progress you get. The more you think you are getting better at what you do, the more motivated you are.
  3. Purpose: the meaning you get from your work. The more what you do matters to you, the more motivated you are.

once you reach the middle class, you should focus on how you make money rather than how much. The way becomes more important than the amount.

Autonomy could be difficult to achieve if you work for someone else…. increase your bargaining power by being very good at what you do. Your company will be willing to give you more freedom if it really needs you. Another way is to build your own business.

GOML-1, Responsive Design

Do you remember when the word “responsive” meant fast?

But now, all of a sudden, the word means: compatible with mobile devices.

what the word “respond” means. You respond to a stimulus. A screen is not a stimulus. A screen is an IO device. You don’t respond to the format of an IO device. You respond to Users. Consarned kids.

Software Craftsmen Are Arrogant, Slow, and Dogmatic

Craftsmen are arrogant.

craftsman in practice—it needs to be done perfectly and proudly. Their focus is fully on minor details, because those create the base from which their skill level can grow.

Software skill exists on an asymptotic curve. When you first learn something, you make large strides immediately and feel like you’re making serious progress toward perfection. But as time goes on, and as you increase your familiarity with the subject, your progress becomes more incremental.

They challenge others to climb the walls and jump to try to close this gap too, and they employ hyperbole to justify the importance of seemingly mundane details and practices. “We need to test this remote edge case.” “Why haven’t you refactored this class?” Craftsmen are constantly working toward an ideal, and any ideal other than perfection is offensive. This hyperbole is not necessary, but it comes from a bias.

This bias creates a communication issue. Craftsmen are so narrowly focused on closing the gap between themselves and mastery that it becomes difficult to consider that others might not share this focus.

They sound arrogant because their language is drawn from a different set of assumptions.

Craftsmen are slow.

In a fast-paced, results-oriented team, a craftsman spends time refactoring working software. This can seem academic or self-indulgent in the face of a deadline. But the reason is both simple and practical.

As craftsmen, we’ve done enough practice to know that the cost of work has a non-linear relationship to its quality. If you don’t take advantage of an opportunity to refactor and increase the quality of your code early, it will take exponentially longer to refactor and add features later. Your code will have more bugs, and will be difficult to extend when your clients need added functionality the most.

Craftsmen are dogmatic.

The first time you neglect to write a test, you increase the likelihood that you’ll neglect to write a test in the future. You’ll develop poor habits, and your skills will slowly deteriorate.

Oct 13, 2014

Thinking about - week 40

Peter Smith - It doesn’t work like that in enterprise

Definition of Enterprise development


What is the solution?

Scott Allen - Building Directives for AngularJS

Meg kell tanulnom AngularJS-t Mese nincs.

Demonstrated how to create custom tags into HTML and have some behavior around it.

Oct 01, 2014

Thinking about - week 39

Craft Conf presentations

Dan North - Jackstones: the journey to mastery

More like a motivational speech but very good. You want to be a master of development.

Until you are novice pretend to be master

But being a master you should be able to use any practice: TDD, SOLID with critique…

Practice until you realize when it is useful.

As a journeyman

Learn how to learn

Listen like you do not know the answer - you may not know.

Gojko Adzic - How I Learned to Stop Worrying…

Amazingly good presentation.

It is focusing how to make agile really working and that is not really about developers but they are wrong too…. I have to re-watch to extract.

We have to change how we are thinking about user stories.

User story is about behavior changes.

Theo Schlossnagle - Responsibly maximizing craftsmanship in software engineering

How software sucks

Specification are extremely difficult to get right.

laziness is promoted as something good.

Learning curve of huge projects is amazingly huge. It become difficult to add features quickly. (!of course not decoupled!)

Learn to hit the fucking deadline:

Learn papers: there are many researches about how to develop big system and resolve problems effectively (heheh történt ilyen mikor valaki bemutat egy design patternt mint valami újdonság és jó design cuccost)

Engineer are function better autonomously

You are judged based on your API

So: choose the proper size of component to be able to work autonomously using well defined API to communicate each other. So build component maintainable.

DO not refactor but rewrite component. Rewrite better, based on knowledge you know about. It is part of maintenance.

SQL is not API!!!

Stefan Tilkov - Architecture War Stories

War stories with humour and fun. Very interesting.


  1. Give feedback
  2. Reflect

Jutta Eckstein - Complex Projects aren’t planable but controllable

Individual goal are against company goals because most of th goal need teamwork which is killed by individual goal setups.

and many other mut it was not so structured to extract the “single message”.

Use values instead of estimates (business values….) for deciding to initiate the project. There are many way to define value (ROI, Risks, Cost of delay, Importance, Willingness for investment)

Plan in different levels: roadmap, long term, mid term, short term

Sep 23, 2014

Thinking about - week 38

All videos can be found on

Doc Norton - The Technical Debt Trap

The danger occurs when the dept is not paid back. Every minute spent on not so good code counts as interest in that dept. Technical dept is good.

People are confused the dept metaphor with the idea that you could write code poorly.

Code must be clean enough to be able to refactor! (always) - Otto: so Tests are there…., well tested :)

Ask yourself:

I any of these are missing it is not technical dept. It is a mess!!!

Remember quality is your responsibility.

NEVER ask permission to do job correctly.

When monitoring complexity track trends not points. (exact values are meaningless but tends are meaningful).

Brendan Forster - 10 Things Ive Learned From Doing OSS

Enrico Campidoglio - Why no code reviews

Problem 1 is about Ego. EGO=1/Knowledge. The less the knowledge the greater the EGO.

Problem 2: you == your code

Problem 3: Fear of making mistakes. Fear of let colleges see my mistakes

Problem 4: Culture o(lack of it) “you are wrong”…. See Ego!

Do not review the person. REview the code. Do not speak in absolute. Fools are speaking absolute.

Time: it need time.

NB: Good diagram about productivity of a geek

What do you get from code review?

When you know that someone is watching you will take care of you code more. “The Big Brother EEffect”

It can eager ambition because yo want to impress your programmer fellow.

Give constructive feedback.

In a project everyone is in the same boat. (Sometimes I do not have the feeling - Otto - But we have to trust people that they are doing their bests)

Kind of review

  1. Formal code review. Most bugs found
  2. Over the shoulder code review. Less former. Less bug to be found
  3. Async code review. Happen async to the code written. “distributed”. IT happens offline. Good compromise in nr of bugs found and time.

Tools: - Gerrit, Diffy


  1. review small portions of code at a time. One commit one logical change.
  2. keep and follow a checklist
  3. keep under 1 hour

Aral Balkan - Free is a Lie

Interesting and shocking conspiracy theory how Google/Facebook is ruling our life and data…

Sep 19, 2014