Comments (0)

By Krishna, January 12, 2010

Bruce Schneier (the author of “Applied Cryptography” and other books) explains why security theater (where security measures do not do much to improve real security) has its benefits:

Tamper-resistant packaging for over-the-counter drugs started to appear in the ’80s, in response to some highly publicized poisonings. As a countermeasure, it’s largely security theater. It’s easy to poison many foods and over-the-counter medicines right through the seal — with a syringe, for example — or to open and replace the seal well enough that an unwary consumer won’t detect it. But in the ’80s, there was a widespread fear of random poisonings in over-the-counter medicines, and tamper-resistant packaging brought people’s perceptions of the risk more in line with the actual risk: minimal. [...]

We make smart security trade-offs — and by this I mean trade-offs for genuine security — when our feeling of security closely matches the reality. When the two are out of alignment, we get security wrong. Security theater is no substitute for security reality, but, used correctly, security theater can be a way of raising our feeling of security so that it more closely matches the reality of security. It makes us feel more secure handing our babies off to doctors and nurses, buying over-the-counter medicines and flying on airplanes — closer to how secure we should feel if we had all the facts and did the math correctly.

The relation to the business world is “management theater”. There are these tons of management processes that don’t do anything to improve the success of the project or prevent its failure. Instead, they are to reassure stakeholders that “proper” management is in place.

The lesson from Bruce’s article is that even though we may want to throw all of such processes out the window, they may actually have an use. Instead of customers becoming tense and worried, and upper management trying to micro-manage the project, some of these processes may convey that the project is truly under control and the project team can be trusted. It can also reduce finger-pointing and place emphasis on improving items that hinder the project.

The tricky thing is to know what process to keep in and what to take out. What Bruce’s article suggests is to ask stakeholders or understand them to see what keeps them comfortable. For example, they get project updates in a specific format at regular intervals. Or the build, testing and deployment process is done in a specific way and is visible to them. The customer may not even read the report, but the fact that they have it keeps them happy.

Comments (1)

By Krishna, November 26, 2009

From the Domain-Driven Design Site:

[A] great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.

Those of us with a software background have a tendency to get mired in the technical details of implementation. All of those discussions around the duct-tape programmers and unit tests and inversion of control. In some ways, it is a good debate to have. But they are just tools to do the actual work, which is to provide solutions to real-world problems.

And in the real world, there is enormous complexity. If you take a business application, there are so many rules and constraints demanded by various departments in the organization. Ignore software for a moment and think of any organization you have worked in. Remember the employee manual? That is just the start, isn’t it? There are so many other de-facto rules for inter-personal or inter-group coordination because of organizational history, etiquette, bureaucracy, etc.

Then there are outside rules by government and standards bodies, to name a couple. The sheer volume of these rules makes it very difficult for any one person to truly understand them all, let alone the inconsistencies and relationships between them. To make matters more complicated, these rules are changing always. Not everything all at once. But one rule here, one standard there – this month, that month. And your requirements keep shifting ground. There is never a fixed target.

That is the real reason why building software is complex. And it is not going to be solved simply by having a better tool or process which only help if you have somehow managed the complexity of the problem. Sometimes, the real-world complexity is, in fact, too difficult to manage. And the best you can do is take a small piece of the problem and try to solve it. Or maybe you can influence the real world to get rid of a business need like, say, end some silly bureaucratic process, and avoid the need to build a complex piece of software.