So What Makes a Good Process?

So What Makes a Good Process?

So what is a good process? This was the first question that came across my mind when I set upon the task of actually drafting a process. Right from the days when I had started of as a software developer to the realm when I have been a project manager for some time, I have come to terms with one reality that development teams should not and they cannot slavishly follow a predefined process, instead, the key is to continually adjust the process as you go by reflecting on what you’re learning, what works, and what doesn’t. So how do we come across or define a good process? Based on my experience I feel that there are some pre-requisites for a good process, which are:

1. A “Good” Process allows you to be fast — without having to reinvent the wheel! I am going to claim, what we all know but seldom admit, –that the fastest way to create software is not to develop anything yourself, but to reuse something that already works. This approach is not just very fast; it is also cheap. It delivers software that works. In practice, in many situations you may still need to develop something new, at the least the glue between the components that you can reuse. We don’t develop our own operating systems, database systems, programming languages, and programming environments any more. We usually start with a software platform and some middleware as a base — not much more. However, much more can be reused:

— You shouldn’t have to reinvent a process. Instead, you should use a well-proven process that is designed to be reused. This is what we call a process framework.

— You shouldn’t have to reinvent the same software over and over again. You should use a process that helps you harvest components and incorporate existing components — legacy systems or other reusable components — into your design. Of course, the process would come with appropriate tools to do so.

2. A “Good” Process allows you to learn as you go — without slowing down the project: Developing software has never been as hard as it is today. As a developer, you need to have a knowledge base that is larger than ever before. You need to know about operating systems, database management systems, programming languages and environments, system software, middleware, patterns, object-oriented design, component-based development, and distributed systems. You also need to know a software process, a modeling language, and all kinds of tools. And if you succeed in learning something, you can be sure it will soon change. Change is the famous constant in the software domain! There is simply no way you will be able to learn all this before you start working on a project. You have to learn a little before, but most of it you will need to learn as we go.

3. A “Good” Process should empower you to focus on creativity: In every project a large portion of the work done by developers is not genuinely creative — it is tedious, routine work that we should try to automate. The problem is that the creative and the routine work are interwoven in microsteps, with each such step only lasting from maybe tens of seconds to tens of minutes. Since these two kinds of activities are interleaved, the developers may still have the feeling of being creative, but fundamentally they are not. Some of you would probably argue that, in fact, you don’t do the unnecessary work. You focus on solving the business problem and ignore much of the other work that does not deliver business value. This is, of course, partly true. However, even in projects where the focus is on code, people have different approaches to good coding standards. What most people thought was good code some years ago is considered bad code today. Thus people spend time on arguing about these things. With a strong, good leader, these problems may be smaller. However, most teams won’t have such a leader. Aside from process issues, we also spend considerable time on many other small, technical issues. For instance, if you want to apply a pattern, there are many small steps you have to go through before you have instantiated the pattern. These small steps could, with proper tooling, be reduced to almost a single step.

4. A “Good” Process uses tools to do more by doing less: Whatever you do, in order to be efficient you need good tools. Good tools are tools that are developed to work integrally with your process. The process and the tools go together. For instance, in examples taken from another world, if you want your carpenter to drive nails in a wall, he needs a hammer, not a screwdriver; if you want your baby to eat on his own, give him a spoon, not a knife. The same goes for software. If the software community ever is going to be more efficient — that is, be able to rapidly develop high-quality software — then we need tools to help us do more by doing less. I agree with the idea that we want a process that is very light. In fact, I want a much lighter process than I have heard people speak about. It will be light because tools will do the job — you will be doing more by doing less.