Tech Answer Blog

The new Opera Unite platform provides a web server through the web browser.  The promise of this app is to provide services that negate the need for a single server in order to connect multiple people, i.e. collaborative spreadsheets or updating applications similar to Facebook, etc.

Assume for a moment that there were an open-source Facebook-like application available on the Opera Unite platform.  Since the application was open-source, and since it has no centralized system, it wouldn’t need to have any advertisements ever (no ongoing infrastructure costs to support).  If users have the choice between two similar services, and one of them doesn’t exploit their content for profit, would users ever not pick that one?

Thus, I believe that the Opera Unite platform or something similar may give rise to serious open-source web competition to commercial websites, particularly commercial social networking or collaboration sites (Flickr, Facebook, Google Docs, etc.)

As more of Information Technology is automated away from manual processes, the manual follow-up has now become mandatory.  Many of the messages generated by automated processes get ignored, and thus system administrators may have to condone false negatives in order to get something done during their day besides browsing through tons of automated messages.  Until intelligent software can appropriately route these messages, users must know to follow up any ticket or automated request with a manual contact i.e. at least a manual e-mail and probably also a manual phone call.  This puts the item(s) back on the appropriate administrators’ radar screens.

The only impenetrable security is that which at a minimum prevents any use whatsoever.  Systems that allow any access are susceptible to at least one form of intrusion: falsified access credentials.

The purpose of information security is to slow down a break-in or use of stolen information to the point where the perpetrator can be captured in the act.  In the case of falsified access credentials, security systems slow down the perpetrator from generating fake access credentials as fast as if the security were not present.

Thus, hackers attempt to find any faster way to generate falsified credentials.  Even if their method is just a tiny bit faster, exploting this speed difference vs. the assumed speed to compromise credentials can buy the savvy hacker time to get away with their crime.

Information Technology security professionals must remain aware of the time necessary to break security, especially in the case when a new form of instant access is discovered (0-day exploits, for example).  Instant access means that a hack attempt would most likely go entirely unnoticed until at least some time after the important data/etc was stolen, and depending on the intrusion method, the most severe of exploit-based intrusions may be entirely undetectable.

Technology project timeline estimation is the lifeblood of all information technology and related consulting efforts.  However, several buried assumptions invisibly affect the estimation process and can cause projects to miss timelines and go over budget.  Being aware of these buried assumptions allows padding for the respective risks, but nothing will prevent the risks from existing.

The most dangerous buried assumptions occur in the following loop:

1.  Changing project requirements at any time after the estimate is made will not cause an overage.  This is the most obvious assumption and yet it remains buried to most customers because of the second most dangerous buried assumption.changes.

2.  Customers or clients develop a false sense of security about the severity or processes necessary to implement change requests.  Without spreading FUD, information technology directors and management must make efforts to give customers accurate information about how long certain changes may take, and the authentic impact expected to the schedule as a result.  Attempting to cover up for slips in the schedule from events in #1 will only increase the effect of any actual timeline slippage on customer retention and satisfaction.

3.  The false sense of security from the customer’s side reinforces the creation of new project requirements outside of the original estimation.  As customers become more confident that their needs can be met at any time, they continue to pile onto everyone’s now unrealistic expectations with more fuel for the fire in the form of additional changes.  These additional changes cause the timeline buried assumptions to loop again starting at #1.

Without a hardline approach that may cost some initial customer satisfaction, the long-term outcome of this loop is to geometrically grow the cost and delays involved in future projects until the point of repeated project delivery failures (once funds and time are exhausted).

This topic presents itself to me every few times I use a computer.   Why do so many GUI’s waste screen space?   Sure, there are instances where you’d want to cleverly space everything out for legibility, or to better define what commands go with what controls, but many GUI’s take this to the extreme.   Here are some considerations when deciding if a GUI is taking up too much space:

1.   Do the controls already exist somewhere else on the page?   If so, consider why you need two sets of controls for the same thing.   For example, Gmail has two sets of controls, one at the top and one at the bottom of the mail list.   Is this truly necessary?
2.   If there are GUI considerations being made, why not allow users to make some GUI decisions themselves?   If I’m an expert user and I want to cram all the controls into the corner, and there’s nothing preventing me from doing so, why not make it an option?   It’s not going to hurt me, and anyone else can just leave it off and use it the regular way.   In the gmail example, I should be able to hide the controls I’m not using — not just with the sidebar widgets that expand and collapse, but with the rest of the screen’s controls.

I think there may be a large cultural misunderstanding with how H1-B visas are used with certain foreign workers.   In the former USSR and as I understand in the Commonwealth of Independent States, it may be illegal to be unemployed.   I think that there may be some misunderstanding for foreign workers in the USA that an H1-B is a license to work, and that if fired they would be somehow under arrest or in trouble.   This is a disturbing prospect and may reflect in the workplace morale, quantity, and quality of work that is associated with the average H1-B worker.   Can any H1-B’s comment on my inference?

Documentation should be a pre-coding activity — documentation is a detailed design of what you are going to build, i.e. a blueprint for the program in human-readable language that describes the technical details of the program.   Adding in documentation after a program is written when no specification or design exists for the program is a futile effort, since most programmers could interpret and produce the same documentation from the code itself.   If a non-trivial condition discovered during maintenance is exploited in a certain block, however, that would warrant notation in the code.   Suppose a repair found that a special condition that was commented out needs to be uncommented out.   You’d want to note why it remains uncommented so that future programmers think twice before commenting it out again.   That might look something like this:

// uncommented: X might not be less than zero when condition ABC happens in module 123
if X<0 then ...

Managing risk in technology is exactly like taking care of a small dog. There are only two ways to handle a dog’s needs: proactively or reactively. If you assume you can tell when a dog has to go outside, you can try to only take the dog out when you see those signs. However, no matter how attentive you are, you will inevitably miss some sign and the dog may have an accident inside. To combat this, you must take the dog out when the dog isn’t exhibiting any signs of having to go out. Technology issues are similarly unable to voice every single time there is a vulnerability being exploited. The best hacks are the ones you can’t see at first glance. Therefore, initiating proactive risk management (PRM) regardless of signs of problems will provide the best safety dragnet for any tech risks. For example, PRM insists that unit testing must be comprehensive and run on a regular basis to be effective. Think of the number of errors that still creep in because someone didn’t make or run a good test on the functionality they added. This testing is a required component of software design when implementing a PRM strategy. In the extreme, reactive vs. proactive risk management is about gambling. Extremely reactive risk management is taking a gamble that if something bad will happen to your business or technology strategy, it will be a minor problem. Extremely proactive risk management is gambling that something bad will happen eventually, and so you should create mitigations for serious problems before they actually happen. Thus, the extremely proactive cannot guarantee they won’t get hit by something bad any more than the extremely reactive. However, the extremely proactive will have a workable solution when they are hit by a bad risk, whereas the extremely reactive will have to come up with a solution after the problem has hit.