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).

I saw a great quote today, page 4 of the Computer Science book “Concrete Abstractions”:

Are there effects we can’t achieve no matter what process we specify? (p.4)

Sometimes a program or process can look like it is working during development, but then more and more signs emerge that the process is somehow flawed and it will ultimately fail.  Being able to point these out in advance as processes that simply will not work using the available tools is a critical skill required to avoid costly and futile CS efforts.

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 ...

First of all, there are general translation errors that can result in code errors based on misunderstood requirements.   This causes some issues, but the majority of issues come from cultural differences.   In India and some other countries, it is considered disgraceful to say “no” to a boss, so certain groups have a tendency to say “yes” to something that they don’t really understand.   I had to work with a group of Korean offshorers that also had this problem.   In order to get something done correctly, you had to set it up in such a way that they could learn or ask questions without seeming like they were saying they didn’t know how to do it.   Businesses that don’t take this into account will pay lots of money into offshoring and get absolutely nothing worthwhile back out, other than a bunch of “yes,l understand” and then about 5 lines of code that don’t do anything.

From one of my Indian friends:

I totally agree with you Devin. Saying “no” to your boss in India is considered as asking for trouble.

Many “experts” are now on some strange vendetta against GOTO and GOSUB; each has convincing-sounding reasons why these commands shouldn’t be used for various reasons in computer programs.   Rather than argue for or against these reasons, I will simply present the following fact:   GOTO and GOSUB work fine if you have designed your program to use them.   However, if you haphazardly use GOTO and GOSUB to skip around in a program, they can cause problems.   They are neither always bad or always good, just as any programming construct can be abused, but I would not discourage anyone from using one if it makes sense to use… provided that you understand how they work (obviously, it’s the same rule with any programming construct).

The moral: a poorly designed program will have errors of all kinds, including GOTO/GOSUB abuses.   A well-designed program, however, can use these commands without logical or architectural penalty.

Devin