P3.express – practical project management framework

When it comes to project management, there are many certifications, guidelines, and suggestions all over the web. But it’s often difficult to pick the right one. Some are overly complicated. Others are too simplistic and don’t cover even the whole project lifespan.

P3.express, however, looks good. It covers the project management process from the early days, when it’s not even clear if the project will proceed at all, to the tasks that need to happen after the project has been fully completed. The whole flow consists of 37 activities in 7 sections, with each one of the activities being well documented and explained.

This one is definitely worth a try. Especially if you ever felt like this:

OPP – Other People’s Problem

I really liked “OPP (Other People’s Problems)” article which talks about handling of responsibility for things that other people should be responsible for.

If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.


This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.


And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.


That kind of grinding frustration can wear you down over time. I know, because I’ve been there. 

Not only the article describes the problem, but it provides a practical approach to dealing with it.

In the last few years, I was going through a very similar thinking process in my head, but I’m nowhere near the well-defined suggested approach. I wish I read this much earlier in my career. Much much earlier.

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.