Archive for April, 2011

Why is software development different from other engineering disciplines’?

Comments Off on Why is software development different from other engineering disciplines’?

Software development is to solve a problem or fulfill a demand using source code for computers.

 

All types of work are based on solving a problem or meeting a need that is more valuable than the money spent for getting this need satisfied. This doesn’t sound that strange, does it? The problem with organization of software development is that it isn’t like any other work, so it is hard to draw conclusions from other industries.

 

I will discuss why software development is unique and why it calls for another kind of organization. There are a lot of factors that make software development a unique field.  This is why it has to develop its own traditions. It is possible to be inspired from other environments like traditional engineering for some aspects; however, when it comes to what we do as a community, our work is no doubt unique.

  • Very few or no physical laws limit us. Software development does not have many limitations that other endeavors have. When constructing and building a bridge, you have to respect the laws of physics. When there aren’t any limitations, a universal theory can’t be developed. The biggest limitation is creativity. When everything is possible, the hardest thing to figure out is how to solve or fulfill a demand in a way that no one else has done.
  • Software development is about design. The final goal in other engineering disciplines is some type of documentation. When a design effort I complete, the design documentation is turn over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. But in software development the only true documentation that can reproduce the product is the source code, so software development is just about design. (Every thought about compiling source code is called “Making a build”!)
  • Design is about handling complexity. Design is about trying to cope with many variables and making trade-off in order to find a solution that suite all expectations. Software specifications tend to be fluid, and change rapidly and often, usually while the design process is still going on. Software development teams also tend to be fluid, likewise often changing in the middle of the design process. In many ways, software bears more resemblance to complex social or organic systems than to hardware. Few things are so hard to handle then when only your creativity sets the boarders, and then you have infinite parameters.
  • Developing software is cheap. Software development is fairly cheap and marketing a software product is much cheaper compared to other undertakings.  For example, a bug-fix is easy to distribute when you compare it to fixing a construction error of a car engine. This inevitably leads to a lot of different behaviors in our industry, but the most important is that it leads to speeding up the work. Quality is seldom more important than speed. You have to have features in your software product before your competitors create those features and before technology changes (again).
  • Software is easy to reproduce. Because it is cheap, developing it also means that reproducing it is quite easy.  Not many industries can easily reproduce a product.
  • Quick evolution. Every aspect of this industry evolves very quickly. Because it is cheap to develop new ideas and to spread these ideas to others, a much larger community can contribute to the evolution. Everyone wants to gain a competitive advantage so everyone adapts very quickly. New ways of working are constantly being developed.
  • Industry is highly competitive. This is not new in this industry. When combined t with the speed of evolution and the low costs to develop unique features that users appreciate, new features are soon developed by your competitors. They could also add better features.
  • Highly intensive degree of knowledge and information. Because everything in the industry evolves so fast, old knowledge is not valued. Knowledge that was highly valued 15 years ago is now considered as something belonging to the Stone Age.
  • Customers don’t know what they want. Everyone learns new things constantly including programmers and customers who use programs.  When customers learn during the process, they make new demands (like requesting special features).
  • Complexity leads to collaboration. Because information and knowledge evolve so fast, nearly no one is capable of managing the journey from an idea to a successful product to satisfied users.

 

This leads us now to the question, what drives change in software development organization?

Market forces lead to intense competition.  People therefore are always looking to improve and gain advantage. In the past, a company positioned itself along a single dimension.  Today, companies that deliver better products that are faster and cheaper have gained the competitive edge. Companies consistently look for ways to cut the time it takes to market their products, and at the same time look for ways to cut costs in developing new products with similar or better features.

 

If you’re looking to gain speed, cutting costs and raising quality, you have to change. In the 1998 book “Competing on Internet Time: Lessons from Netscape and its Battle with Microsoft”, MIT Sloan professors Michael A. Cusumano and David B. Yoffie, wrote,  “The pressure to release new software products faster and faster has grown over the years… ten years ago, development cycle of 24-36 months were typical, today, a year to 18 months development cycle is normal for software products … Within ‘emerging fields such as electronic commerce and web portal sites competing on the Internet, time demands significant product and feature changes every three to six months’”.

In 1998 this was probably a futuristic statement.  If you asked people then, they probably wouldn’t have imagined a lifecycle from idea to market of up to 18 months. Young developers would think of this statement as coming from the times of the middle ages and the Black Death.

 


Trying storytelling with Prezi.com

Comments Off on Trying storytelling with Prezi.com

At Sigma we have decide to try storytelling about business cases, so decided it could be a great opportunity to learn Prezi’s presentation tool. I wrote a little story and implemented it in PowerPoint and then just made it a Prezi presentation instead. Totally it took 5 hours from idea to a finished presentation. The Prezi part was really easy and you learned the foundation of the tool on 5 min. Here is my story. (It’s best watch in fullscreen, you find fullscreen on the “More”-menu)


Craftsmanship

Comments Off on Craftsmanship

Because we work in a more complex environment where our work is more exploratory in nature,  it doesn’t mean that craftsmen don’t have anything to teach us. Allan Cooper, author of “Running with the Inmates” and inventor of Visual Basic, said the following about craftsmanship:

Craftsmanship is all about quality – it’s all about getting it right, not to get it fast. It’s measured by quality, not speed. It’s a pure measurement, and a delightful one.”

Craftsmen do it over and over again until they get it right. In their training, they build things over and over so they get the experience they need to get it right.[1]

This demonstrates the concept of personal competence but this also has a disadvantage.  I’d like to explain by quoting one of my favourite blogger – Joel Spolsky – and how he answered the question of what his view on craftsmanship was.  “Craftsmanship is, of course, incredibly expensive. The only way you can afford it is when you are developing software for a mass audience. Sorry, but internal HR applications developed at insurance companies are never going to reach this level of craftsmanship because there simply aren’t enough users to spread the extra cost out”

My conclusion, therefore, of craftsmanship is this:  it is the pride that a craftsman takes in his profession and tools. Because he performs based on his personal competence, he prioritizes the mastery of his tools, upgrading them and improving his work methods in an evolutionary way. Craftsmen take pride in personal improvement and appreciate quality because they know how valuable work becomes when done the right way. They know that quick-fixes will rarely be successful in the long run, you still have to fix it later and that translates to even more work.


[1] http://benzilla.galbraiths.org/2009/06/04/craftmanship/


The Evolution of Leadership Styles

Comments Off on The Evolution of Leadership Styles

In the earliest period of industrialism, Taylor and Fayol created new ways of administering work more efficiently by centralizing power. Earlier, I talked about the planning, organizing, staffing, directing and controlling model. The foundation of this model was that uneducated labor was hired in factories and they where managed by people who controlled the whole process. This was based on the assumption that the manager knew more than the laborer.Evolution of Management

The style by which these managers led others echoed the dictatorial style of  “you do it my way or you don’t do it at all”. As the labor force became more competent, the managers’ roles shifted. Managers learned to delegate parts of the working process in the new “Empowerment style”, “Do this but do it your way…”. When power was decentralized, the creative and innovative energy of employees was released. Management trusted employees more and mistakes were regarded as part of the learning experience.But in a more complex world where the future was more uncertain and managers didn’t know “what should be the right thing” or “How the right thing was done” a new way of management came about.  With Toyota as one of the biggest examples of Kaisen and Lean, everything will improve and will be done just in time.  Consequently, management had to change into “follow me and let’s figure this out together”. It became an exploratory journey. We can’t fully understand the problem until the first solution to the problem is delivered. And we won’t know if it is the right solution. The right solution (what) is discovered along the way and solved in ways never done before (how).  Therefore, what is needed to succeed in this trip into the unknown? This approach enabled Toyota to implement a million new ideas a year.  This is why Toyota made more than twice the money as any other carmaker. Toyota has truly demonstrated what a culture of creativity and innovation can do.

A new kind of “manager”

In traditional non-knowledge-based companies, the title of “Manager” often implies that a person is either responsible for a lot of people or earns a high salary, or both. Nowadays, there are a lot of managers that have neither formal power over people nor earn higher salaries.  instead they are responsible for a specific situation.

They are assigned to be advocates for a specific intention, area or goal. Within this goal, their responsibility is to understand what makes this intention as successful as possible. A project manager is someone who is responsible for making an intellectual journey into the unknown, taking a specific context from one starting position to a much brighter and more valuable future.

Management these days is about taking responsibility for a situation. In Jeffrey Liker’s book “The Toyota WayToyota’s leaders are described as leaders who are clear about the purpose and direction; at the same time they remain close to the business  and have a deep understanding of the work. A manager needs to have a deep understanding of the Value to the customer. The value consists of “the right thing” for the customer and that the work is done “the right way” for the customer.

The Toyota Way

The Agile Reaction

Agile methodologies have been around for a while and have been adapted with varying degrees of success.Agile methodologies constituted a reaction against the more document-driven and plan-driven methodologies like RUP.  But Agile work was also a reaction against the traditional way of management (bureaucratic management and task management).

Software development is true knowledge-based work, which means that the persons in the team doing the work know most about the whole system, not the managers as in a factory. This puts the managers in a new role where other things are demanded.

The Agile Manager – the Knowledge-based Work Leader

If management is more about taking responsibility for a specific situation, value is created primarily by the team’s knowledge and creativity. A friend told me a story about curling. Each curling team consists of 4 players and one is the team leader. Everyone in the team plays stones and helps out with the sweeping. The manager leads the work with the strategy, discussing with each member but at the same time is an active player himself.

Sometimes the players need to get on the track and help the other players out, sweeping in front of other players’ stone to give it the right speed and direction. Agile management is similar to this. the Agile manager is the player that helps out with the knowledge-based work but his most important responsibility is to help others perform as much as possible and to focus on strategy and execution.

When I look at myself and my work, the times that I feel becoming engaged in the “production and operations”, I soon lose sight of the macro perspective of the development.


Predicting Complexity Leads to Guilt and Guilt Lead to Apathy

2 Comments »

Predicting Complexity Leads to Guilt

When you work as a project manager you are expected to be in control. To control and review things, you must be able to predict things. To be able to predict things you need a plan.

The most common planning and control tools are GANT and PERT diagrams. But for a PERT diagram to work, it needs to be accurate and must rest on the assumption that it’s predictable.

How is this possible in a complex and complicated world? These types of tools give the project manager a sense of control. With this tool the project manager can control the holy trinity of scope, cost and schedule. Every real project manager has full control of these parameters; otherwise, he would be a fake.

But what happens when the project manager starts to experience the noise? A feeling of being out of control takes over. The second effect is that he feels guilty and asks, “With the information and resources I had, did I do my best? I’m not in control and I should be. How and why did this project fail? Is there any way to save my reputation when this project fails?”


When doubt and guilt get hold of a project manager, he does not focus on making the best software; instead he focuses on regaining control. No process or methodology is a crystal ball where in you can look into the future, only because he made an initial plan.

It may sound like I dislike GANT and PERT diagrams. Not at all! They can be very useful, but if they are your sole foundations and tools for organizing and controlling your project, I’d say you could develop an ulcer!

Guilt may Lead to Apathy

When a project manager’s work is based on a reliable process that produces predictable results and the manager feels that he did everything by the book (which must be right), he starts to wonder if the team followed the process.

Maybe the developers didn’t follow the process or aren’t doing what they are supposes to.  This can lead guilt, doubt and blame to spread within the organization. When people feel they are trying hard and doing their best and still fail to live up to their own expectations, they will eventually stop trying to do their best.

If I am confronted with failure even when I do my best, it’s best to just mind my own business. Why care about things that I haven’t been assigned to work on, and get blamed for things failing?

When this happens, things could be overlooked. They fall through and apathy takes over. To control this situation, the project manager has micro manage everything. The traditionally defined software development process is broken. It’s not a predictable tool that leads to repeatable results.

Let’s stop fooling ourselves, software development isn’t civil engineering. We don’t have 10% construction that leads to a 90% predictable production. When projects are complex and noisy, no process can be defined in advance to obtain a repeatable result. The solutions must be an adaptive and empirical process control.

Predicting Complexity Leads to Guilt

When you work as a project manager you are expected to be in control. To control and review things, you must be able to predict things. To be able to predict things you need a plan.

The most common planning and control tools are GANT and PERT diagrams. But for a PERT diagram to work, it needs to be accurate and must rest on the assumption that it’s predictable.

How is this possible in a complex and complicated world? These types of tools give the project manager a sense of control. With this tool the project manager can control the holy trinity of scope, cost and schedule. Every real project manager has full control of these parameters; otherwise, he would be a fake.

But what happens when the project manager starts to experience the noise? A feeling of being out of control takes over. The second effect is that he feels guilty and asks, “With the information and resources I had, did I do my best? I’m not in control and I should be. How and why did this project fail? Is there any way to save my reputation when this project fails?”

When doubt and guilt get hold of a project manager, he does not focus on making the best software; instead he focuses on regaining control. No process or methodology is a crystal ball where in you can look into the future, only because he made an initial plan.

It may sound like I dislike GANT and PERT diagrams. Not at all! They can be very useful, but if they are your sole foundations and tools for organizing and controlling your project, I’d say you could develop an ulcer!

Guilt may Lead to Apathy

When a project manager’s work is based on a reliable process that produces predictable results and the manager feels that he did everything by the book (which must be right), he starts to wonder if the team followed the process.

Maybe the developers didn’t follow the process or aren’t doing what they are supposes to.  This can lead guilt, doubt and blame to spread within the organization. When people feel they are trying hard and doing their best and still fail to live up to their own expectations, they will eventually stop trying to do their best.

If I am confronted with failure even when I do my best, it’s best to just mind my own business. Why care about things that I haven’t been assigned to work on, and get blamed for things failing?

When this happens, things could be overlooked. They fall through and apathy takes over. To control this situation, the project manager has micro manage everything. The traditionally defined software development process is broken. It’s not a predictable tool that leads to repeatable results.

Let’s stop fooling ourselves, software development isn’t civil engineering. We don’t have 10% construction that leads to a 90% predictable production. When projects are complex and noisy, no process can be defined in advance to obtain a repeatable result. The solutions must be an adaptive and empirical process control.