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

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.

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

(Notes) Note subdesign elements requiring additional research, test cases or proofs of concept (poc’s). Make sure to do these items first and factor results or limits back to design or requirements as necessary, to prevent/minimize issues. Example: Main design > sub design 1 (with its own requirements, design research, design and code, test, etc). Note limitations of sub design with respect to feasability of main design, based on reliance of main design on the subcomponent.
1. Are there impacts to the current requirements based on the design? For example, do the requirements cause feasibility issues in design? If so, send these impacts back to requirements phase. The project parts that are not impacted may continue forward, but the release should be adjusted to account for additional necessary changes. If not, then the release can be expected to have a number of predictable problems, costing significant time and money overages as compared with an appropriate design-time adjustment.

2. Research design limitations for workarounds and risks thereof. If there are limitations and risks, send these back to requirements as necessary.

3. Analyze design for overly complex or elements in need of a design refactor, note for phase two, or implement changes to design before coding.

These are the questions that have to get answered in order to successfully deliver a software engineering project, in whole or in part, by an individual or team.

Phases: Requirements, Design, Config, Code, Test, Rollout, Troubleshoot, Other

Requirements questions:

1. Do you have all the requirements collected? If not, collect some more from whomever can supply requirements to you or the team. If there are any unanswered questions re: the existing requirements, then you don’t have all the requirements yet.

2. Are the requirements strong, firm and understandable, and agreed upon in writing by the supplier? Having the requirements in writing is the only way to guarantee that all parties have had a chance to comment on the requirements as they are understood by the developers. If this step is not taken, feature creep will plague your project.

3. Are all the risks for the given requirements spelled out and accounted for? For example, if there is the risk of a project overrun based on an especially difficult requirement, then make sure this is spelled out in the requirements document. If it is not written down, then the client can easily say that they didn’t know the project would cost more or go over. It is the responsibility of the engineering team to make the client aware of these issues up front whenever possible, or to at least indicate where there may be issues, if the issues are not yet entirely apparent.

4. The project should be able to move to the design phase, provided that all of the above questions are answered sufficiently.

If you plan before acting, you will have a much higher probability of catching mistakes before they actually happen.   I recommend planning out any complicated activity, listing options and possible side effects, before taking action on a project.   The plan becomes the documentation for what was done, so in case something does actually go wrong, the steps to reproduce the problem are apparent.

I was recently referred to the following article:

http://www.igda.org/articles/erobinson_crunch.php

This article discusses why working in “Crunch mode”, i.e. a lot of extra hours per week, sabotages the work environment and almost guarantees significant errors resulting in a loss of any effort gained in the short term by the longer hours.

I additionally would like to contribute that working a set block of hours during the day actually has very little to do with having high output for any creative job. Creative output comes in bursts, and based on every single creative person I’ve ever seen, I’ve never seen anyone that could truly produce an assembly-line like level of creativity evenly all day long. A much more accurate picture of their creative output looks like a wave, with extreme peaks and troughs throughout the day. During the troughs, if they have something non-creative to work on, they tend to work on that during the creative trough. When the creative person is experiencing a creative peak, they can easily accomplish a ton of creative work accurately. To try to force production of creative output during a trough basically won’t work. If there are no non-creative items to work on, the individual may as well not work at all so that their creative energy is recharged.

Imagine that creative energy feeds off of regular energy also, so if regular energy is at 0, creative energy can’t be as strong. If they burn off all their energy and then have to be creative, they aren’t nearly as productive as if they are creative in bursts, recharging energy in between. I argue that the creative person can do 40 hours per week, but it may not be a specific block of 8 hours per day for 5 days in a row.