Tag: project management

Why software projects take longer than you think – a statistical model

“Why software projects take longer than you think – a statistical model” is an interesting take on the problem of bad estimations in software projects. I’m not that great with math, but even then the article is very interesting. And there is a lot that I agree with.

Here’s a quote for those of you who couldn’t make it through:

Why software tasks always take longer than you think

Assuming this dataset is representative of software development (questionable!), we can infer some more numbers. We have the parameters for the t-distribution, so we can compute the mean time it takes to complete a task, without knowing the σ for that task is.


While the median blowup factor imputed from this fit is 1x (as before), the 99% percentile blowup factor is 32x, but if you go to 99.99% percentile, it’s a whopping 55 million! One (hand wavy) interpretation is that some tasks end up being essentially impossible to do. In fact, these extreme edge cases have such an outsize impact on the mean, that the mean blowup factor of any task ends up being infinite. This is pretty bad news for people trying to hit deadlines!

Redmine: Estimated Time as mandatory field

At work, we are using Redmine for all our project management needs. It is a flexible and powerful system that allows flexible configuration for the processes of most companies.

Recently, we have decided to make the Estimated Time field mandatory for all the tickets. Configuring this turned out to be trickier than I thought initially. I couldn’t find the option to do so on the first go.

Some Googling around suggested that Redmine’s source code needs to be modified for that. Not something that I wanted to do. And the tip is also from 8 years ago, so it’s probably quite outdated.

After digging deeper, I found a way, that doesn’t require source code changes. This can be accomplished via editing the Field Permissions in the Workflow. Here’s the process (for Redmine 3.3.0 stable, that we run currently):

  1. Login to Redmine as administrator.
  2. Navigate to the Administration screen (a link in the top bar or so, depending on the skin you are using).
  3. Navigate to Workflow.
  4. Switch to Field Permissions tab.
  5. Select desired roles and trackers.
  6. Press Edit button.
  7. Scroll down to the Estimated Time field.
  8. Select Required from the dropdown for each status, as needed.
  9. Press Save button.

You are all done. Now all tickets of the above selected trackers will require the input of the Estimated Time for all above selected statuses and roles.

Similarly, you can make other fields required or read-only, as per your company or team needs.

How to Slow Down to Go Faster Than Ever in Software Development

While reading through “How to Slow Down to Go Faster Than Ever in Software Development” I couldn’t help but nod my head in agreement continuously. The article goes over the well-known and familiar challenges in software development, but it also words them in a very simple and straight-forward way. It’s difficult to disagree with.

Here are a few quotes to get you started.

As Robert C. Martin mentions on the primary value of software at CleanCoders, “The ability of a software system to tolerate and facilitate such ongoing change is the primary value of software”. Rushing is evil in software development. Any attempt to rush causes dramatic damage in productivity, focus, people’s effectiveness, adaptation capability, and tolerance of software.
For instance, we always have time for fixing bugs, but no time for writing tests. We don’t refactor and write tests because we don’t have enough time. But we have time for debugging, hacking code and fixing bugs.
We focus on processes so much that we often forget the main asset in software development: people. Processes help people to improve the way they build products, increase motivation and cultivate a healthy environment. In the end, the efficiency of processes is important, but people are crucial.

Processes and tools do not build products, but people do. We have to admit, “talent hiring” is the most important functionality of an organization. It has direct impact on the future of the company and the product itself.
Hire the best talent for your organization. By saying “the best”, I do not mean the smartest, or most experienced people around. I look for passion, discipline and motivation at a minimum. If all three exists in a talent, the other skills can grow with ease. Hiring is a win-win process, so both sides should gain from the process. So you should slow down your hiring process and invest on improving it. People join companies in which they believe. So model the behavior you want to see. And through your company culture, your vision and people, make talent believe in you.

One thing is clear. Without having a quality codebase, you cannot be agile, sorry. The first thing you need to do is eliminate technical debt and resolve bugs. If you need to stop building the features for a while, and focus on eliminating bugs.
“Fixing bugs and deploying to servers afterwards” is not a proper procedure today. It contains risks and danger. We need a better and more disciplined way of doing it. When you want to fix a bug, first write a test and reproduce the problem programmatically. Then fix the bug and see that the tests are passing. Deploying to production is safe afterwards.

NASA: 100+ Lessons Learned for Project Managers

Jerry Madden, the former Associate Director of Flight Projects at NASA Goddard Space Flight Center (GSFC), collected 122 lesson learned nuggets from a variety of sources that are instructive to managers of NASA spaceflight projects.

While these are mostly around NASA projects and problems, many are very applicable outside as well.

Here are a few to get you started:

  • Don’t be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.
  • Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
  • Reviews are for the reviewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.
  • Mistakes are all right, but failure is not. Failure is just a mistake you can’t recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.
  • The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.
  • Software now has taken on all the parameters of hardware, i.e., requirement creep, high percent-age of flight mission cost, need for quality control, need for validation procedures, etc. It has the added feature that it is hard as hell to determine it is not flawed. Get the basic system working and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world the newer version works. It is necessary to have contingency plans for software.
  • Reviews, meetings, and reality have little in common.
  • You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager. There are simple courses available to learn “computerese,” “communicationese,” and all the rest of the modern ese’s of the world. You can’t manage if you don’t understand what is being said or written.
  • People who monitor work and don’t help get it done, never seem to know exactly what is going on.
  • There are still some individuals who think important decisions are made in meetings. This is rarely the case. Normally, the decision-makers meet over lunch or have a brief meeting to decide the issue and then (at a meeting called to discuss the issue) make it appear that the decision is made as a result of this discussion.
  • Management principles are still the same. It is just the tools that have changed. You still should find the right people to do the work and get out of the way so they can do it.
  • Integrity means your subordinates trust you.
  • There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people and employ their services when necessary as soon as possible. Getting the work done by someone else takes two to three times longer, and the product is normally below standard.
  • Never assume someone knows something or has done something unless you have asked them. Even the obvious is overlooked or ignored on occasion– especially in a high-stress activity.
  • A person’s time is very important. You must be careful as a manager that you realize the value of other people’s time; i.e., work you hand out and meetings should be necessary. You must, where possible, shield your staff from unnecessary work; i.e., some requests should be ignored or a refusal sent to the requester.
  • The project manager who is the smartest man on his project has done a lousy job of recruitment.
  • Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you cannot.
  • The boss may not know how to do the work, but he has to know what he wants. The boss had better find out what he expects and wants, if he doesn’t know. A blind leader tends to go in circles.
  • In political decisions, do not look for logic– look for politics.
  • Too many people at Headquarters believe the myth that you can reduce the food to the horse every day till you get a horse that requires no food. They try to do the same with projects, which eventually end up as dead as the horse.

Monorepos: Please don’t!

I have only recently discovered the concept of monorepos. It does sound interesting and I am yet to try it out, or, at least, dig deeper into the subject. But then, there are people who have strong opinions against them, and I the reasoning makes all the sense to me. Here’s a nice one: Monorepos: Please don’t!