Wow, 700 billion dollar bailout.
A few weeks.. or was it months?.. or maybe it was yesterday.. I can't tell time.. Anyways, at some point in the past I ranted about the lost opportunity that was the Iraq war and how they could have used the money on several other projects. That amount was 500 billions dollars. Now they want to spend 700 billion.
For comparison, canada's national debt is now 467 billion dollars. Aiii!
To be fair they say that they'll get the money back.. Well, most of it.. probably.
It's only ~2000$ per man, women and child in the US. Canada's national debt is ~15000$ per person which is still pretty bad given that Canada's population is about 33 million vs the US' 300 million or so.
Congress, at this writing, is balking at this amount. Honestly, I don't blame them. This is a ridiculously large amount of money and as much as I can appreciate the occasional need to prevent contagion, this is on a greater scale then.. well.. anything I've ever hear of. Honestly, I'd give this a miss too without some really convincing evidence that they know exactly what their doing.
I wonder if Colin Powell would consider giving another speech.
Monday, September 29, 2008
Wednesday, September 10, 2008
Communication between engineers and management.
Human beings work on two levels. The first is the emotional level. This system is very good at making very quick decisions based on the data but doesn't think very deeply. The second level is the rational level. This is the level that can do mathematics and understand software design. Psychologists think of these two levels as being different systems in the brain. They call the first level system one and the second level system two. Given that there's absolutely no way of understanding a very complex piece of software, like an operating system, if someone's trying to explain to you what's special about the newest version of Windows or Linux or MacOS X, there may be a little technical data transmitted however the bulk of the information will be directed directly at system one, the emotional system.
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.
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.
Monday, September 1, 2008
Learning is fun
Well, you learn something everyday. This is especially true if you're working with computers. Today I learned the following:
1- windows file sharing permissions are weird.
2- Entourage X (mac outlook) will irreversibly corrupt its database if you push it over 2 gigs.
3- Sylpheed doesn't know how to import an mbox file if said mbox file uses mac style line ending.
4- Sylpheed crashes most spectacularly if you try to import a 1.6 gig mbox file with mac line endings.
5- Practically no text editors will work with 1.6 gig files.
6- Knowing how to program in Java and having a development environment ready to go has its advantages.
Tune in next week when I learn that beating oneself over the head with a pan is a good stand-in for using a computer.
1- windows file sharing permissions are weird.
2- Entourage X (mac outlook) will irreversibly corrupt its database if you push it over 2 gigs.
3- Sylpheed doesn't know how to import an mbox file if said mbox file uses mac style line ending.
4- Sylpheed crashes most spectacularly if you try to import a 1.6 gig mbox file with mac line endings.
5- Practically no text editors will work with 1.6 gig files.
6- Knowing how to program in Java and having a development environment ready to go has its advantages.
Tune in next week when I learn that beating oneself over the head with a pan is a good stand-in for using a computer.
Subscribe to:
Posts (Atom)
Posts
