The Mindset

I know. It’s been ages (well, weeks, but still). Don’t worry, everything is OK. Even great! So, what I’ve been up to?

Well, I hate to say it, but I just got a little tired with writing. No, not for good. But I felt I needed a break. I found myself spending 9 hours a day in front of a monitor at work, and then spending 2–4 more at night writing. That’s way too much for any normal human being, both physically and mentally.

So, at first I just used my free time to do nothing (i.e. watch television ;). A couple of weeks later I suddenly felt like this is a great time to go back to my hobby from a couple of years ago: photography. I also decided that while I’m at it, I should indulge myself with a new camera (time to go digital).

Ironically, this decision “forced me” to spend 4 (“free”) hours a day for the past two weeks researching, comparing, reading reviews… on the Web. So, I found myself staring at my monitor even more than before. But that’s it. Today, I finally bought a camera!

Anyway, here’s what’s going to happen. I am NOT ditching this blog. Believe me, I have a lot on my mind. I just need the time to “dump” it. I’m just… slowing down.

Meanwhile, it would be great if you would continue to be not only faithful readers of this blog, but also faithful viewers…

You are all invited to visit my Flickr page. It’s currently still very modest, but I hope it will soon grow. Comments (as always) are welcomed.

So, till the next post (better sooner than later)… say cheese :D

A couple of weeks ago I wrote about code which doesn’t deserve to be maintained. I received a lot of comments on this post. Many of them argued that unlike tangible goods, code does not decay. Some people referred me to Joel Spolsky’s article, saying that throwing away code which was already tested and used on the field is never a good economic decision.

In my response to these comments I clarified:

“If you get a piece of code and you assume it was well taken care of, you might be… well, wrong. That’s why you have to check. Saying that any piece of existing code is better than a new one doesn’t make sense. If, for example, the previous owners of the code did a lousy maintenance job, you might end up with code that requires you to invest weeks of work for each small change. You can try refactoring that mess, but this is not always possible or cost-effective.

Joel’s article and your comments are 100% right in an ideal world where most of the code out there is reasonably maintained. I’m not sure this is the reality we all work in. But in any case, it’s better not to assume anything and just make sure you check the status of the code before making a decision.

I don’t like black and white rules. Unlike Joel, I try not to use phrases that begin with “Never…” or “Always…”. Just keep your mind open to the option that sometimes a rewrite is better than refactoring.

Of course, you should do it wisely. Don’t wake up one day and throw away 500K lines of code. Do it incrementally and with proper safety nets. But keep in mind that this is a valid option.”

Then, a couple of days ago I came across this paragraph in Jerry Weinberg’s classic book Quality Software Management Volume 1:

“In time, existing code may even come to have a negative quality, meaning that it would be cheaper to develop new code than attempt to keep repairing the old. Many pattern 1 and pattern 2 organizations are holding large inventories of negative quality software, but usually they are unaware of that fact. Or if they are aware, they are so unsure of their ability to develop new code that they continue to limp along patching ever more pitiful and expensive systems.”

Maybe it’s just me, but this sounded awfully familiar. I just couldn’t believe I read this paragraph only after writing my post. Well, there you have it. I guess you should keep your options open, and keep in mind that sometimes starting over again is the right thing to do.

Dear CEO,

What do your people feel when they wake up in the morning and have to go to work? Is it something like “I wish I could just wake up when the weekend starts”, or is it more like “oh well, I guess I have no choice, do I”? Or is it something completely different?

You probably know the term “user experience”. When you create a product, you want the user to have a good experience. You want the user to have a WOW experience. You want your users to come back for more. And you want this feeling to last. But today we are not going to talk about your users. We are going to talk about another group of people whose experience is at least as important. Have you ever considered the effect of the worker experience?

Yes, I know: “we pay our workers to come to work and do the best they can”. Well, here’s a newsflash: this is not enough! You may think your people feel good. You may count on your average (or less than average) turnover rates. But that’s not enough ether. There’s a great difference between not looking for a better job and feeling that “this is the right place for me”. Your people, like your customers, want a WOW working experience. And they want it to last.

Knowing that, some companies go out of their way to pamper their workers and create the best working experience they can. Most of them do it the only way they know how: spending money. Great food, amazing offices, the best computers, furniture and facilities, great salaries, cars… anything goes. And you know what? It works! All these things do create a WOW effect. Judging from the amount of words written about the Herman Miller Aeron Chair you’d think that it can do your work for you. The question is, does this effect last? Does your Herman Miller chair make your people happy when they have to go to work day after day after day after day?

So, back to square one: what is it that makes people want to go to work and come back for more? And how much would it cost you? (Hint: less than redecorating your offices).

People want to work in an open and honest environment, where they can speak freely and know they will be heard. People need to know they make a difference. People want to know they are trusted. They have to know they can also trust back. People need to know they are appreciated for doing good work. They have to feel what they do is important. People need to hear a good word when they deserve it. A genuine good word. They want to be part of a community — working together toward a joint vision. People want to be treated as equal human beings regardless of their rank.

If your people have all that, it doesn’t matter if your office decor is out-dated, or if you only have $100 chairs. If your people have that, they will have something to expect when they go to work every morning. They will have a warm feeling that everything is in place — that they belong. It’s not that everything is perfect. But your people will know that it can be.

***

“Is this really WOW stuff? It sounds so elementary”. Well, it is. At least it should be. Unfortunately, in the current business climate these things are much harder to find than offices with Herman Miller chairs. So, the answer is “Yes. This is WOW stuff”. If you want to recruit the best people, if you want your people to become better, and if you want them to stay and really give 100% of themselves, you’d better start working on it. And the best thing is that while none of this stuff is easy to achieve, it’s all free.

A friend of mine sent me this article and asked me for my opinion.

The basic premise of the article is simple: if you want to know exactly how a certain tool, technology, or process, improve the productivity of your staff, you cannot just measure how much time it saves. If a certain tool saves ten minutes a day per developer, for example, "we all know" that at least part of this time will not be used for doing productive work.

“When productivity returns from IT are measured, time saved does not equal additional time worked. Using a correction factor to account for the inefficient transfer of time allows accurate and structured the quantification of returns from increased productivity.”

So, the article continues, we need a Productivity Correction Factor™ (trademark of Nucleus Research Inc.) to correct our estimate of productivity gain from deploying a new tool. Naturally, this factor can only reduce the estimation — no one can be more productive than what you expect him to be, right? So in fact, this simple numerical factor can now tell you how much time your staff is wasting, or, in other words, how unproductive they are.

The whole idea of representing the productiveness (or in this case the unproductiveness) of a human being using a single number is flawed. I’m really curious to know how a CEO reacts when he reads his marketing personnel are half as productive as his service representatives. I personally know some managers who will try to come up with innovative ways, such as limiting Web access, to prevent their stuff to waste so much time. After all, its company’s money they’re wasting, isn’t it?

But you know what? That’s not even the real problem. The real problem lies in the underlying assumption that any minute that is not used directly to create money for the company is a waste of time.

Let’s say that out of each hour you save by introducing some new technology or practice, your developers will spend 45 minutes on online games and random conversations by the coffee machine. Does that mean productivity is increased only by 15 minutes? Is it possible that the time your developers spend on "meaningless activities" is in fact an indirect productivity enhancer? Is it possible that the time they "waste" on stupid games helps your developer be more focused and do a better job in the rest of the time? Have you considered the option that some of the best ideas are born in random conversations?

People are not machines. Measuring people’s productivity as the percentage of time they spend on their primary task is relatively easy. But that doesn’t make it a meaningful measurement. People, and especially people doing creative tasks, might spend much of the time on other things beside their primary task. This is not necessarily a waste of time. On the contrary, it’s probably an essential ingredient of the creative process.

The problem is that many managers think that in order to be in control they have to have "accurate" measurements of every part of the process. The unproductiveness factor is just an extreme example. Many in the software industry still think about productivity in terms of the number lines of code per developer per unit of time, the number of bugs per tester per unit of time, etc. Each of these measurements is as inaccurate as it is easy to calculate. Trying to capture a complex concept, such as productivity in a creative process, using simple factors and measurements can easily lead to the wrong conclusion. With these wrong conclusions and the bad decisions that follow, you will eventually decrease productivity instead of improve it.

Instead of deconstructing the process into meaningless numbers and measurements, it’s sometimes better to look at the overall picture. If you are evaluating a new tool, a new technology, or a new process, consider using some soft evidence. Use the new tool in a pilot project, and then try to understand its effect by talking to your customers, your developers, and other stakeholders. Will you come up with an accurate number reflecting the return on investment of using the new tool? Well, you won’t. But you will have a much clearer picture of the effect this new tool had on your development process and on the product or service you provide.

For years, it has been said that things that cannot be measured cannot be managed. Now, think of all the things you manage in your life even though you have no way to measure them. Is it possible that some aspects of managing a team, a project, or even an entire company are also unmeasurable?

Used cars. That’s what’s on my mind these days. My wife and I decided that we need a second car. But judging from the time it takes us to find one, I’m not sure we are really serious about it. Well, we are, but here’s the thing…

You see, I’m just too paranoid to put my money on a used car. A car someone else drove. A car someone else took care of. Did the previous owner treat the car well? Did he change the oil on time? Was he careful not to push the car to its limits? And how many owners did the car have anyway, and who were they? I just don’t know, and this uncertainty makes me think twice (OK maybe it’s more than twice) before I place my bet on that car (or another).

Cars just don’t get better over time. You know that. And in the wrong hands, it might get even worse. So, how can I possibly buy, not to mention drive, something like that? I know, everybody else is doing it, so why can’t we? We can always have the car checked before buying it. That’s not the 100% guarantee, but it’s the least we can do.

***

Used code. Used code is a lot like a used car. I’m really paranoid when it comes to used code. Code someone else wrote. Code someone else took care of. Did the previous owner of the code make sure the code works as expected? Did he write the code such that I can work with it as needed? And how many owners did that code have anyway, and who were they?

Like cars, code cannot live forever. It can be used for years, but just like with cars, as time passes it costs more to maintain and keep in a good shape.

Everyone knows the term “code decay”. But not everyone realizes it is a natural tendency that affects every piece of code. That is not to say that we shouldn’t write quality code. The better the code we write is, the more resistant it will be to this law of nature. Just like a well-treated car lasts longer than a neglected one.

Code should be written well to begin with. It’s also important to have routine maintenance on your code (refactoring, remember?). But as the case is with used cars, you should follow some guidelines to ensure you won’t find yourself with an unusable (and maybe even dangerous) wrack.

1. Don’t assume your code will live forever. Do what ever you find reasonable to write it so it lasts. But always be prepared to say “this code has served me well, but it’s time to let’s go now”. Hanging on to your code after that point means spending a lot of money on recurring (and futile) repairs.

2. Be suspicious. Being somewhat paranoid has never hurt anyone. Before you take a piece of used code under your responsibility, make sure you will be able to safely work with it. If the code you have to maintain looks like a car you wouldn’t even take for free, consider the option to go for a newer model.

3. Look under the hood. When you are going to work with a third-party component, it might be useful to have a look at its code first. Not every vendor will allow it, but if you don’t ask, you will never know. A short glimpse at the code will help you know if you are dealing with a component that has a future or with a component with a tragic past.

***

A colleague of mine once said that every piece of code should have an expiry date on it, after which you have to throw it away. I don’t know if I would go as far as that. But it might be nice if every piece of code would have a warning on it saying, “would you drive this code if it were a used car?”

A picture is said to be worth a thousand words. A good picture is priceless.

In my line of work I often find myself in need to describe processes, dynamics, and interactions, to help me, and the people I work with, to understand the systems they are part of better. Understanding the reality you operate in, and the way you can affect it, is the first step toward making an improvement and building a better reality.

For me, as the facilitator of this process, one of the greatest challenges is describing this reality accurately. I am, of course, not the first one to come across this challenge. In his book The Fifth Discipline, Peter Senge introduced system diagrams as an aid for describing complex systems. Gerald Weinberg suggested diagram of effects as a medium that can help us “grasp how things interact” in his book Quality Software Management. And, of course, there are the more traditional workflow diagrams, flow charts, and others. Each of these tools offers a way to express a certain aspect of our complex reality.

Now, I know some people prefer a simple whiteboard as the ultimate sketching tool. And indeed, in some cases a whiteboard is the most effective tool for making the first steps in creating an effective diagram. But I have to admit, I for one love fancy tools (as long as they help me deliver better results). And when it comes to making a visual impact, I am not going to settle for a whiteboard.

This is why I was thrilled to come across SmartDraw 2007. SmartDraw is great for a couple of reasons. The most noticeable one is that within a couple of minutes you can create impressive diagrams that really make an impact. After about a month of using it, I can safely say that people just love the result. The diagrams are so attractive and diverse that people just can’t get enough of them. But this fact doesn’t come at the expense of the real value the diagrams have. SmartDraw makes it easier for you to create diagrams that carry vast amount of information, and still draw people’s attention to where you want it.

But maybe the greatest thing about SmartDraw is the fact that I can create my own object libraries. I can create, for example, a library for diagram of effects with reusable diagram parts and objects. So now, whenever I need to create a new diagram of effects, I have all the building blocks ready for use.

What more can I say? It’s easy, professional, and… smart.

Yesterday, I wrote about ten software development myths, which unfortunately are still around. In his comment to my post, Tim King wisely argued that the ten myths I had listed were all big-company myths.

Tim, I know you said you are going to write your own top-ten small-company myths and misconceptions, but I just couldn’t resist the temptation. Sorry.

I recommend reading the following list side-by-side my previous top-ten list. Oh and by the way, it’s not really about size. It’s about mentality. But let’s not spoil the fun.

10. The manager’s task is easy: he should merely translate anything marketing demands into a task. This is, of course, a one-to-one translation because whatever marketing asks is sacred and has to be done in the highest priority. 

9. Documenting design (or anything for that matter) is a waste of time. By the time someone needs it, Google will buy our company.

8. Hmmm… what reviews?

7. Software development is pure art. And as Charles Horton Cooley said “An artist cannot fail; it is a success to be one”.

6. Software development is 100% creativity. We’re still looking for innovative ways to squeeze 25 a day hours into 24.

5. Creativity and discipline cannot live together. Discipline equals stagnation.

4. The answer to every challenge we face in the software industry lies in doing more work in shorter times. And if you want this solution to be scalable, just double your work force.

3. People don’t need processes. Just put a bunch of them together in one room and they will get the job done.

2. The ultimate software development process is: raise money – hire developers – create a mock up – sell company.

1. Quality is… let me see…. hmmm… it’s… haaa… sorry, what was the question again?

Today, I’m going to start with the bottom line: we still have a long way to go.

No, there’s nothing new about it. If you’re a regular reader of this blog, you probably know all about the misconceptions and myths the software industry suffers from. But today wasn’t any ordinary day, because today I had the “pleasure” of hearing so many of these misconceptions packaged together in what might look like a coherent view on software development at first sight.

Discussions about software development in general and quality in particular are part of my daily routine. I don’t know if I’ve heard each and every myth out there, but I think I can safely say I’ve heard most of them. But I have to admit that today I found myself overwhelmed by the volume of myths that split the air is such a short time.

So, as a special service to my faithful readers, here are the top-ten myths and misconceptions I’ve heard just today. If you hear more than five of them together, run (or be prepared for one heck of a discussion).

10. The developer’s task is easy: he should merely translate the design document into code. This is, of course, a one-to-one translation because the design document already deals with any dilemma a developer might come across.

9. Every design decision is documented before it is implemented. Otherwise, how on earth can we expect developers to do nothing but translate the design into code.

8. Reviews are a one-time effort. All you have to do is take an artifact after it is completed, and verify that it is correct. Code reviews, for example, should merely verify that the code is indeed a one-to-one translation of the design.

7. Software development should be like manufacturing. Each of us is a robot in an assembly line. Given a certain input, we should be able to come up automatically with the right output.

6. Software development has nothing to do with creativity. The only part which requires creativity is designing your assembly line. From that point on, everyone should just be obedient.

5. Creativity and discipline cannot live together. Creativity equals chaos.

4. The answer to every challenge we face in the software industry lies in defining a process. That process defines the assembly line without which we are doomed to work in a constant state of chaos.

3. Processes have nothing to do with people. You are merely defining inputs and outputs for different parts of your machine.

2. If a process is not 100% repeatable, it is not a process. Letting people adapt the process and do “whatever they want” is just going back to chaos again.

1. Quality is all about serving the customer. Whatever the customer wants, he should get. Things that don’t concern your customer should not be of interest to you.

As I said, I guess we still have a long way to go…

In one of my next posts I will address each of these myths.

One of the things I hated as a teenager was being told I should grow up already. Whenever I was told that, my immediate reaction was “You don’t understand anything. YOU grow up!”. Undoubtedly a typical reaction for a teenager. Not to say an immature reaction, which is what got me that far in the conversation in the first place.

Time has passed and hopefully I have become more mature (although some people will argue otherwise). How did it happen? I really don’t know. But it was certainly a process — one that never ends.

In my previous post I wrote about the ineffectiveness (and sometimes even danger) of trying to use good tools in an immature organization. Many have asked in response a perfectly legitimate question: how exactly do you turn an immature organization into a mature one? The short answer is I honestly don’t know. But that won’t make a good post, will it? So, let me refine my answer: it depends.

First, we have to understand who we are talking about. How can a virtual entity be said to be immature? Well, an organization is not really a virtual entity. It is made of people. When we talk about the maturity of an organization we refer to the way people communicate, interact, perceive reality, and advance toward a shared vision. Together, they create a culture — an unspoken organizational subtext — implicit, yet known to everyone.

You can try to change the organizational culture from the bottom up — starting with the people at the lowest levels of the organization. In fact, you will find it quite easy to convince these people in the necessity of a change, because they are usually the ones who suffer the most from the immaturity of the organization. But the lower you aim, the harder it is to create a real change.

Saying the truth in a room full of people who don’t want to hear it, is hard. It’s even harder if these people are accustomed to covering up the truth and creating a facade that everything is under control. And if there’s a slight chance the truth will create the impression that they are not in control, you are doomed.

If you’re trying to change that from the bottom up, you have to deal with too many management levels. Each of them can put an unhappy end to your effort.

Don’t get the impression that I argue you should be dishonest and align with your immature organizational culture. But don’t expect to be able to win this battle. You should be ready to face the consequences of your honesty.

So, your other option is to start at the top. Top management cannot dictate an organizational change, but it can lead the way by example. If top management encourages openness and honesty, if it accepts even the strangest ideas and the toughest criticism as a basis for open discussion, people will soon start to behave accordingly. If cover-up and dishonesty are discouraged, people will soon cease to use them.

But here lies the problem. If you want to convince managers to change, they have to acknowledge the fact that they have a problem. They have to be open to criticism. They must have a strong sense of reality. In short, they have to be mature. At least they have to be mature enough to accept the fact that there’s a lot of immaturity they are probably responsible for. And here we are back at square one.

Now, there’s always the chance that the “leaders” of your organization will be really eager to listen to what you have to say, and will even accept it. Maybe they have what it takes to accept the idea that somewhere along the way something got wrong in the way the organization is managed. But I’m willing to take a risk and say that’s rarely the case. I don’t have any statistical data to back me up, but I do have a strong feeling you have to be prepared to face a strong reaction.

So, I’m not too optimistic about changing well-rooted organizational culture without the true commitment of management. Does this mean you should give up? Hell no! You should be loyal to your beliefs and to your ideology. You must trust your instincts and treat others as you want them to treat you. You must follow your heart and your common sense.

If this doesn’t work in your organization — look for a better one. Better yet, create a better one. If you have come this far, you have a great chance to succeed. By the time immature organizations come to their senses, they will be too far behind to be of any significance.

***

Looking for something to read on your way to work? Try The Fifth Discipline.

Related Articles:

• The Incapability Immaturity Model
• The Root Of The Matter

A car is a wonderful tool. It can get you from one place to another quite effortlessly (well, assuming the two places are within reasonable distance). For most of us, cars are cost-effective and convenient. They serve their purpose amazingly well, at least until some higher form of transportation emerges.

There’s a lot to consider when you buy a car: its size, its fuel consumption, its popularity, maybe its color, and certainly its cost. But there’s one thing we take for granted when we go buy a car. No matter what car we are looking at, we are quite sure it will be able to serve its main purpose: to transport us from one place to another.

Unfortunately, when not used correctly, this allegedly innocent tool can actually be a dangerous weapon. If you drive recklessly, ignoring the road conditions, other drivers, and common sense, there’s a fairly good chance you will not only hurt yourself but also others around you. But even if you drive safely, but your car is poorly maintained, you can lose your brakes or have one of your tires explode. If this happens when you’re driving 80 mph it can get very nasty.

To use a car correctly and safely you need more than a driving license. You need a lot of common sense, and a great deal of restraint. You need to know the limitations of this tool, but you also need to know your limitations as a driver. You need to have respect for other people using the road and for life in general. To be able to actually get from one place to another using a car you need a great deal of maturity.

None of us thinks about it when we buy a car. A mature person doesn’t need to, because he already has what it takes to be a good driver. For him this is natural. The tragedy is that immature drivers – the ones that should really think twice before using a car — are not mature enough to understand the problem they have to begin with. They probably won’t acknowledge their problem even when something awful happens.

About a month ago I wrote about the inability of tools, processes, techniques, and standards such as ISO, RUP, SCRUM, XP, Agile, UML, TDD, and others to deliver the promise they carry: to improve software development. Each of these tools has its pros and cons. Each of them can help you deliver great products. Unfortunately, each of them can also be misused.

And here lies the irony. A mature organization, with a culture of openness, honesty, and introspection, is able to wisely use almost any good idea out there to improve the way people within it create software. When the same tools are being used by immature organizations, however, they are bound to cause more harm than good.

Burn-down charts with fantasy estimates, cover-up reviews, detailed UML diagrams that carry no useful insight about the internals of the product, and high coverage of degenerated unit tests — can all be more dangerous than doing nothing. They create the illusion of control — of a well managed project — while in fact, they are merely a facade for nothing more than plain old chaos.

For an immature organization, this is just perfect. As long as things are perceived to be in control, they are. And when eventually something disastrous happens, you will always be able blame the tool or, even better, that people using it. Because immature organizations don’t have the ability to look inside themselves and realize that no matter what tools they use, it is the organizational culture which is ill. A mature organization would have this ability, but then again, a mature organization will not find itself struggling with these problems to begin with.

What none of these tools offers is a way for immature organizations to grow and become better. Experienced people with a lot of common sense, wisdom, and intuition, conceived these tools. But these tools were all designed to be used by exactly such people, just like a car is designed to be used by mature drivers. For people to achieve this degree of maturity, they have to operate in a supportive culture – a culture that makes them room to grow in.

People in a mature organization know that. People in an immature organization cannot possibly begin to understand where the problem is. They will always try new tools, methodologies, and techniques, which work perfectly well for smarter organizations. Most of them will keep blaming the tools they use (and some of their people) for their failures.

***

See also part II: Grow Up, Will Ya!