DMAnswers

Screen Space Wasted by GUI’s Revisited

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.

H1-B Visa Cultural Confusions

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 in code during coding

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

Culture Clash in Information Technology: Don’t Take “yes” For an Answer

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.

Debunking the anti-GOTO/GOSUB vendetta

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

Software Engineering required questions, part 2: Design (Notes)

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

Software Engineering Required Questions, part 1: Requirements

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.

Plan to Find Mistakes

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.

Maximum Productivity is not Linear to Hours Worked

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.

Strategies for dealing with BBM code, part 2

Fixing temporary invalid state code and ugly code are both difficult and/or time-consuming operations, but there are easy ways to at least protect the existing code until such time that a rewrite can be considered.

To fix temporary invalid state code, simply wrap the offending areas in the appropriate state validations. For example, suppose that you know that A can’t be more than 5 when a certain procedure is called, and yet whenever an A greater than 5 is passed in, bad things happen. Wrap the procedure in a check that A is not greater than 5, and make sure that the check errors out gracefully and prevents the procedure from running, etc. This strategy is a foolproof and simple way to prevent invalid states. Granted, the invalid state shouldn’t be allowed to get entered in the first place, but the goal here is not to reinvent the system, but to inexpensively issue an effective patch. After all, if you were going to do more than this type of patch, wouldn’t you just want to redo the whole thing since it’s all so gross?

Fixing ugly code is next. Suppose that the only thing left now is all these gross patches to the temporary invalid state code, and a bunch of just “ugly” code. Now is when you can carefully refactor a section at a time, so that the code makes sense. Be sure to start in the innermost area, so that the refactorization doesn’t inadvertently introduce bugs. Recompile, test and validate the refactorization like crazy. It does no good to refactorize if it doesn’t still work at least as well as before, without introducing any other errors.

Carefully design and plan out each refactorization, listing any side effects or drawbacks, and then analyze whether those side effects or drawbacks can be prevented w/o more … side effects and drawbacks. If not, then DONT do that particular refactorization. You don’t want to get stuck in a refactorization loop, where each change breaks something somewhere else, and an ugly but functional system turns into a pretty, non-functional system.

Note: This will insult and shock most junior and artistic programmers, but just because code looks “gross”, that doesn’t mean it’s not working or that it’s not good enough for now. The money was already spent to produce it, so replacing it with something that provides no additional benefit other than looking different is wasteful. One person’s crap code can be one person’s great code, although I’ve seen my share of code that is just crap to everyone… this is how to deal with the latter.