Very often explaining the positive and negative aspects of the complex design doesn't involve trying to make people understand the whole system, even when the system itself is really only understandable as a whole. It's possible to transmit one's excitement about the system or the elegance of the system through one's own excitement and a few choice examples. You need to transmit your excitement because otherwise your words come off as disingenuous. You need to use a few examples because this is something the brain can understand. In antiquity we weren't always able to prove things mathematically so what we did instead was we used anecdotal evidence. Examples are like anecdotes. They don't have the advantage of being associated with a different person, but if you can make your example personal and that's almost as good.When it comes to engineering, one of the greatest dangers and engineer faces is misunderstanding a system. To simply not understand a system is not as much a problem because you typically know that you don't understand the system and seek out knowledge, advice and otherwise treat the system with respect one would expect to give to a potentiality dangerous blackbox. When an engineer misunderstands the system he feels free to tinker with it, to change it and then put it into production. Many bugs in software actually exit because an engineer changed the system, either data feature or fix a bug, but didn't understand how that existing system worked. As a result of their tinkering they introduced a subtle problem. As a result, software engineers, in fact all engineers, tend to become professedly more paranoid about misunderstanding concepts as they get older.
This sort of paranoia about misunderstanding a system does not exist in the general population. In fact, it may not even exist in engineers with respect to non-technical matters. When people not in technical roles interact, in such ways that can influence the design and manufacture of complex engineering system, there will almost certainly misunderstand the system.
Working on a complex piece of software requires holding a lot of state in your head. It acquires understanding in detail the software system. In a typical day a software engineer will make many decisions that will affect how long it takes to build a piece of software, how robust that piece of software will be and whether or not a feature gets implemented. He will make these decisions either explicitly or implicitly based on the design he chooses to implement. While requirements suggest design design suggests requirements also. A good engineer will optimize the time it takes to write the software, the quality of the software, and the number of features in the software. Frustratingly for managers, the only person who actually has enough information to be able to make the trade-off is effectively is a software engineer. Frustratingly for software engineers the only person with enough information to be able to understand whether the system should be optimized for speed of development, quality or features is the manager.
From the manager's perspective, it is impossible for manager and to know everything they need to know in order to make a design decision that will influence the schedule, quality and capability of the software their team is building. While I think it would be possible for managers to be able to do this with certain high level features. However, in practice a good designer will be able to understand the whole system in its entirety and for any given set of features, schedule and quality objectives will be able to optimize the design, in its entirety, to the optimal. A common manager mistake is to try and exert control over the software team by withholding important prioritization information.From the software engineers perspective, it's impossible to know exactly which of features, schedule or quality is most important given the current political climate. This includes pressure from clients, budget pressures and maintenance duties. A common software engineer mistake is to build the wrong thing to a ridiculously high standard.
Communication between management and software engineers is tricky. From the software
engineers point of view, he can't give the whole picture because it would simply take too long. In fact, if you were to give the whole picture to the manager to manager would know the same amount as a software engineer about the system. Nevertheless, software engineer doesn't need to give an accurate picture of how the system works. All we need to do is give some idea as to the emotional landscape of the solution space. Essentially, any combination and quality features will result in a schedule with some risk parameter. Negotiating a combination of quality, features and schedule is the process of understanding the solution landscape and then picking a solution with an agreeable combination of factors and a tolerable risk.A manager can help speed this process along by attempting to communicate the political climate, as much as it relates to the priory of features, the satisfaction with current quality and schedule pressure to the engineer. By doing this the manager gives the engineer context as to what sort of environment the software is being built in. This process is very similar to going to visit an on-site client to find out what sort of workplace pressures the client is under and what sort of environment the software is expected to run under. While a manager can drag and engineer round with him to get yelled at by executives the manager can try and communicate as much as possible the current priorities.
Managers need to be over trust are software engineers to make the right design decisions. This is a matter of professional trust and competency but also a question of having the right information.
Software engineers need to try and poll their managers and under other members of the organization for what the priorities are what the priorities are likely to become and how satisfied everyone is with the current state of affairs.
Posts
