7 Rules for Efficient Software Production

1. Understand the IT Mentality

The Software industry is a mix of science, technology, art, and business. It is quite difficult to navigate there without understanding these aspects on a good enough level. The biggest problem is that the industry itself is quite complex; therefore, best practices are complex too. You need to learn a lot and verify your knowledge by practicing a lot to succeed.

The incredible technology update rate makes it doubly tough. Nothing you learned ten years ago is needed anymore. So you need to learn at an accelerated pace.

Summarizing all the above, we can say that succeeding in the IT field is not based on innate skills or feelings but on hard practical examples. Never ever “follow the gut” or believe solely based on feeling, including yours.

The best practice in adopting new ideas is to verify that somebody did it before and it worked.

If yes, the idea is worth considering. Otherwise, demand a very good and very detailed explanation on how choosing this path makes your team’s life better. If it passes this test, schedule a lightweight proof of concepts project that experimentally proves it fits into your environment.

The important thing to understand here is that there are no right and wrong solutions because there are many ways to solve software problems. However, there are good and bad understandings of the solution.

If a person can clearly articulate idea in detail or draw a link from adopting this solution to the team’s success to persuade other team members, then we can rely on this person’s vision and hope for the high chance of success.

2. Don’t Mix Production and Development Methodologies

Software production is based upon software development. However, these two have completely different goals, mindsets, and practices. Trying to solve a problem from one of these realms with the methods from another produce ridiculous results. It is important to understand the distinction and to use appropriate methods for each of these worlds.

Software development is a combination of art and craft. The art component will always be there regardless of automation tools and methodologies out there. Therefore, solving development tasks requires maximum concentration and shielding from all other distracting signals.

The best way to motivate an experienced developer is to present them a task in its pure technical form with all human factors excluded. All requirements should be also expressed in technical language. They should be easily verifiable to allow them to navigate toward the goal during their solo research phase.

Software production, in contrast, is more in the business administration domain. You know what your customer needs from one side and you know what team resources you have at your disposal from another. So now you try to direct your team efforts to reach the goal. Meanwhile, you can also estimate your progress speed and present a well-versed plan to the boss. The important skills there are understanding your customer’s wishes, understanding your team’s strengths, and communicating formal plans and schedules.

This being said, I’d like to highlight that many roles in software development are working in both of these worlds—in building a bridge between business and technology—such as team leaders, architects, analysts, and project managers. People in these roles should be able to walk easily between two planes of reality and understand when it’s time to talk business and when it’s time for art.

3. Use Persistent Storage as an Extension to Human Memory

Human memory, although amazing in capacity, has its limits. You remember things with unpredictable accuracy and duration, and when you forget, there is no way to recall it at will.

That’s why we use persistent memory storage to move along at a predictable speed. This is not about formal documentation like user’s manuals that you create long after the fact and for other people to use. This is about using documents literally as your memory’s external extension during the work that helps you to go through the process.

CodeoDesk do not encourage people to process a lot of tasks at once. On the contrary, the fewer tasks you have, the better. Not many work situations are truly human-optimized, though, and multitasking may be required and you have to handle it some way. The above trick helps to handle it better.

4. Don’t Waste Time on Formal Time Estimation

No two projects are alike. The next time you do a similar project, you will have different customers, different goals, a different team; maybe even different technologies. Even using standard tools and components, you will still need to customize their configuration and architecture. When you handle software projects, keep in mind than they involve somewhere between 50% and 100% custom work. They require research, discussions, thinking, trials, and other highly unpredictable activities. In practice, you may experience an enormous difference in what appears on the surface to be the same exact project type and what you’ve done before. A new project type, by extension, is almost impossible to estimate exactly.

If it is so unpredictable, than how are project managers supposed to present a project schedule and stick to it?

There is one formal method of doing this described in the literature; namely, to split the whole project into smaller steps, estimate how long each step takes, and then calculate total project length by combining the work length of individual pieces. There is tons of theory behind this method taught in MBA courses.

Unfortunately, though, no amount of math can save it. This method is notoriously inaccurate, to the extent that it is completely unusable and impractical, not to mention how incredibly time consuming it is. I never saw a project manager that was using formal calculation methods without any adjustments, not even among methodological fanatics. Not even when the company strictly imposed such method usage! In fact, the best performing managers use completely different alternative methods, as described below:

A good project manager tunes up their gut feelings by studying and observing lots of past projects.

A good project manager takes notice of the project type, environment, resources involved, organization type, and all other work aspects influencing the actual project length. Of course, nobody needs to learn solely from their own mistakes. Such observations can be done both directly and indirectly; for example, through books or by studying projects done by other people or even by merely passing the knowledge person to person. Such statistical top level knowledge improves personal project schedule navigation.

5. Understand the Cost of Switching Tasks and Juggling Priorities

The human mind is amazingly engineered by nature. Even though it is incredible, it has its limitations. In other words, it designed to excel in particular areas and in a particular type of task.

A developer’s mind is definitely a great asset in software development. Would you, as a project manager, be interested in understanding it better and put it into a position where it performs the best?

Let’s put it in simple terms, avoiding too much theory. Remember, theory only takes you so far before you need to learn from experience, either your own or from others.

The human mind has strong problem solving and idea generation potential. Unfortunately, it is not always possible to tap into this potential, mainly because to support idea generation, you need to keep all pieces of the problem together in your active memory at the same time. That’s why solving complex problems go through a simplification stage when a task is generalized or reformulated to cut out unimportant pieces and to decrease the number of elements kept in memory simultaneously. In other words, we can either solve one very narrow complex problem or multiple simple problems.

Another important human mind trait is its inability to switch between tasks immediately as computers do. Indeed, you cannot just stop thinking about something at will. You can’t immediately start thinking about a new concept at your full speed either. That sort of mental inertia is perfectly illustrated by air traffic control operators. Even though they are looking at the radar and seeing the whole picture, they still need to load it in their memory to operate quickly. It takes ten minutes for a new operator to watch the screen before they can replace the old one at a shift change.

When people experience this kind of “task carousel,” they lose all sense of achievement and realize that this project is going nowhere.

A good manager stands up and shields the team from such minor disturbances by absorbing the emotional shock-wave and converting it into productive future discussion items. That is definitely hard emotionally, but it’s the only way to keep the team in good working rhythm and to let them deliver.

6. Value Team Players

Most IT industry professionals were asked on an interview whether they are good team players or whether they work well in a team. Yet, probably nobody ever saw clear definition for it in literature. Obviously, such a person would contribute to team success in general, but few people can actually define distinctive personal qualities assuring such success.

Communicating

The first and foremost quality, of course, is an ability to communicate.

Imagine a person with zero communication abilities. Surely receiving no feedback from team members renders them completely useless. This is so obvious that nobody is actually measuring this skill during the interview, which implies that the skill is at a good enough level as long as person can talk well.

Communication is not a binary yes/no skill; it is more of an information transfer window. The wider it is, the faster and clearer the information exchange.

Communication skill is a multiplier for all other skills the person has.