mobcode

Your job is not to “help”

Some people define their role as inflicting help on people. Don’t do this. If you are a consultant, do not define your role as helping the team. If you are a manager of a team, do not define your role as helping. If you are in business as a smart technical person do not advertise yourself as offering help. If you find yourself doing this then translate the word “help” to “annoy” and you will see more clearly.

To define your role as “helping” is condescending and passive. The ego it takes to define your role in life as helping others reflects a fundamental misunderstanding of the universe. Instead, redefine your role to define what you are individually doing, what you are accomplishing (and this cannot be helping). Then as a secondary role you can be open to providing assistance to people who request it.

Suppose you are a consultant who primarily trains teams in development processes. Do not define your job as helping teams to implement good processes. Instead define your job as providing training. If in the course of providing training someone asks for your assistance then by all means help them. By focusing on providing training rather than helping, you will focus on getting your job done rather than focusing on all the deficiencies of your client and your responsibility to fix them. You will turn your critical eye on yourself to learn how you can more effectively prepare and deliver training.

While defining your role as helping sounds quite generous and charitable it actually reveals an unhealthy, egocentric attitude.

School is a terrible preparation for work

School trains people to think there is a predefined point of success. School trains people to place an upper bound on success. School prescribes a set of lectures to go to, a specific number of assignments to do. Tests have a limit. The best you can do is ace the test. There is a fixed number of classes needed to get a degree. School instills the notion that there is an upper limit on success and it is reached by getting the right items checked off on a predefined list.

School is antipreneurial. It opposes entrepreneurial thinking. Coding for money on the web means you are operating your own business. Entrepreneurial thinking is what you need to be successful coding for money on the web. School is a terrible preparation for working on the web.

Build a prototype instead of a proposal

When you first start working on an application you can create an end-to-end working system in a remarkably short time. I don’t just mean a false demo that provides screens that don’t work. I mean a real working application. Now it will be very short on features. It will be an anemic application. But, it will be a working end-to-end system.

Some developers will not deliver a working end-to-end system quickly. Instead they will write specification documents, build data models, create architecture diagrams, build frameworks, construct development environments, do UI design, create detailed estimates, etc.

Some developers are scared to show sponsors a working system early, because the sponsor will never understand that the application is not finished, it is merely started.

Use the fact that you can create a working application very quickly to your advantage. Use this to win business. Use this to win real engagement with your sponsor.

If you are bidding on a project, instead of producing a proposal, produce the first version of the application. Imagine the buyer comparing a written proposal with a working app.

If you want to really engage with a sponsor and get them excited about the project, then show them a working prototype instead of a proposal.

And don’t just do this once, keep doing it. If you deliver new features that the sponsor wants every week then you will become an ally of the sponsor rather than an antagonist for them to fight against.

Fires kill productivity

In order to be productive you need a short list of things to focus on. When you focus on an item you get it done.

Fires are the urgent items that pop-up throughout the day and demand immediate attention. These urgent issues kill productivity. They kill productivity because their urgency encourages us to take on too many tasks. Their urgency almost forces us to multi-task. And multi-tasking kills productivity.

So my question is, why do fire houses always appear so neat and orderly? If firemen are always fighting fires then how do they have the time and discipline to keep their trucks washed and everything put perfectly in its place?

Sieze slack time

There is rhythm to life. Times change. One day there is intense pressure to get things done. The code needs to be finished immediately, there are production problems, or some such thing. Then a few days later there is apparent calm. Nothing is obviously broken and there is no immediate pressure to deliver. What to do in these times?

One answer is to work ahead. Attack the list of things to do as if there were immediate pressure. Why? Because there is a good chance that tomorrow things will change and the app will need to be done. If you work ahead now then you can alleviate that pressure in advance.

This is in essence what the planning game is all about. It takes the tremendous pressure that is felt at the end of the project and brings that back in time to the beginning of the project. By forcing hard decisions about priorities to be made early the planning process some of the end pressure is moved to the beginning of the process. In this way, the pressure is distributed and the ultimate pressure is relieved.

What else can you during slack times? This is a great time to invest in some strategic efforts that can shape the entire project and be leveraged for the duration of the effort. For example, invest time at the beginning of the project to establish automatic build servers and automatic testing. These efforts set the project on a trajectory that will become the standard for how the project operates.

Whatever you do, realize that the slack time will not last and seize it to drive the project on to greater success.

Be ready to ship at a moment’s notice

The software game is unpredictable. The customer might decide they need the software today instead of next week. Or the priorities might change and you will be called off of your current task. To ensure that your work is not wasted it has to be ready to ship at all times.

Do your work in such a way that is is always done. Not that it is completely done, but it is always partially done. The key is that it must be ready to ship at a moments notice.

How do you do that? You first implement features as thin, end-to-end strands. Then you bulk it up one additional strand at a time. To put it another way: first get a rough version of the feature working, then add the bells and whistles, one-by-one.

Don’t thrash

Another way developers act like computers is they thrash. You have seen your computer do this. You try to run too many things at once. The computer runs out of memory and starts swapping to and from disk. You hear the disk grinding and performance grinds to a halt as the computer is stuck constantly swapping back and forth to disk. Nothing gets done.

This is most obvious in developers when they take on too many tasks at once. Either individually or as a team. There are so many different features under development that all of the time is spent switching between tasks. The developer is rushing around from task to task. Much energy is expended. There is much activity. But as the activity increases the amount of work that gets done decreases.

Perhaps this is seen as a flood of emails flying about. People are asking questions, getting confused, trying to establish the background understanding, and this is all happening on twenty features at once. It is too much to keep organized and so the efficiency plummets.

The solution: do one thing at a time. Pick a feature, talk about it, prototype it, repeat a few time until it’s done. Then move on to the next one.

Developers should not halt

Developers tend to become like the silly machines they program. When a computer runs a program and encounters an unexpected situation it halts. The program stops running. In some cases the computer stops running. If the user want the computer to start again then it is the user’s responsibility to go in, remove the offending data and restart the program.

Sometimes developers do this. They are asked to do something, they start to look at the problem, they encounter something they don’t understand and they stop. Maybe they come to a crossroad and they identify two choices. Maybe something like: “should this be implemented as a database constraint or in application code?” Unsure of which choice to make, they take the fatal choice of stopping and punting the issue back to the sponsor.

This always feels arbitrary to me. Any problem can be divided into an endless set of design choices. Any one of those choices could be declared a show-stopper and bang… development stops.

If developers don’t feel empowered to make the choice then why do they feel empowered to halt?

Needless to say halting is not a desired behavior. Imagine this happening in a cluster of many developers. The project sponsor must walk around resetting stuck developers all day.

Build two to get one

When I attended this software development conference a couple of years ago there was much talk of how to decrease risk on software projects. One suggestion that came up several times was having two separate teams work indepedently to implement the project. This seemed to be mentioned, not as a real possibility, but merely as a thought experiment.

If you work on the web there are two factors that turn this thought experiment into a real option:

1. High chance of failure
2. Cheap development

When a project sponsor hires a developer across the web there is a good chance the developer will never produce anything useful. Or the developer will be so busy on their day job that they can never focus on the project. Or there will be communication issues that prevent you from ever establishing a good working relationship with them. Not to mention all of the normal project risks that make every project take much longer than expected. This is a problem. It is hard to have confidence the project will be done soon.

But, global competition on the web is driving software development costs down. Project sponsors can afford to hire two developers to work on the exact same thing. This basically doubles the chances that the sponsor will get working code.

Often when developers find out this is happening they are concerned. It seems so inefficient. It just seems wasteful and wrong. However, developers need to understand that there are different parameters to optimize. Instead of trying to optmize the project cost, the sponsor is focusing on the need to deliver.

Learn from lean manufacturing: don’t blindly optimize your own work

Agile development has borrowed ideas from lean manufacturing. The two are compared very well in this article. One idea from lean manufacturing that developers need to learn is that it is not good to focus on local optimization, but rather the focus needs to be on a responsive and smooth overall output.

Each developer is functioning as part of a larger system. The goal of the system is to deliver working software to end users. Often developers will focus too much on their small piece of the world. They will optimize what they are doing so that they are producing work at the maximum rate. This is understandable from a developer perspective, but as lean manufacturing demonstrates, it does not lead to optimal results overall. One of the key, non-intuitive, results of lean manufacturing is that each stage of the process is not to be locally optimized to produce at its maximum rate. Allowing one stage to produce at a different rate than the overall flow of product merely creates additional work-in-progress. That work-in-progress becomes a cost drain, a productivity drain, a quality drain, and a responsiveness drain. It is bad.

Developers need to raise their head and look beyond a short-term focus on their small part of the world. They need to be aware of the overall end-to-end flow of working software to the users. They need to make sure that flow is happening rather than just doing their work as fast as possible.

If you do this you will help your team deliver better software more reliably. This will make you more valuable to project sponsors.

NOTE: I know the comparison between software development and manufacturing is dangerous and flawed in many ways. However, that fact should not keep us from learning.