19
November
2005
Can it be that the mouse causes “context switching” (for humans)? Any emacs user (as any gamer) will testify that using those (seemingly frightening) key bindings doesn’t require any “brain cycles” and happens almost automatically. This is why emacs is so perfect for quickly jotting some thoughts without real distraction1.
Certainly there are applications with attractive GUIs and loads of features to manage lists of various kinds but are they really used? Not by me or anyone else I’m familiar with. What if the context switching cost is too high. And if so can it be the mouse? Actually there is another suspect—switching to a different window. I recently came to suspect that using the mouse to switch to another window/application causes simply de-focus the user. This might explain why all the application with rich GUIs and admittedly good features can’t convince users to use them for a long time. On the other hand plain textual lists with no sorting and filtering capabilities (not to mention archiving, outlining, sharing and publishing) are found much more useful2.
Interestingly, writing a note on a piece of paper does not set your mind wondering in other directions as writing a new Outlook task (or in an endless number of to-do lists, PIMs or project management application).
1 Check out John Wiegley’s planner mode for emacs.
2 As mentioned in Meet the Life Hackers .
Posted under Life hacks
22
October
2005
I’ve been struggeling with to-do lists of various kinds for years and I’m constently looking into ways of improving my productivity. Are Getting Things Done and various Life Hacks my saviours?
PigPogPDA – PigPog Creativity Wiki . This definitely looks promising and I’ve started following the methodology sketched there (actually something similar).
GTDTiddlyWiki – your simple client side wiki . Cool javascript implementation but I don’t think I’ll bother with it. I miss my emacs key bindings (surely not a problem of this cute tool)
Posted under Life hacks
18
October
2005
Nothing is more dangerous for the development process than losing control of the project complexity (think of a star collapsing into a black hole). The team must develop a feeling for complexity and know when a task should/can not be done or when a technology or a design should not be used or followed for fear of complexity taking over.
There is also a soft, human side to it—developers who are uncertain of the application are likely to make grave mistakes anywhere along the development process. They are also likely to pass on this message of uncertainty when working closely with the client. Then you are dealing with suspicious clients…
The “keep it simple” meme should therefore be understood as Keep it Simple to Understand and Control or “keep it easy”. Beware of simple solutions that may be correct and even elegant but are too abstract or just not easy to understand.
Dealing with human nature
The “keep it easy” mantra is best understood when projecting it onto the development and integration process. Everything that simplifies the team’s life should be seriously considered. The opposite is equally true (or even stronger). Therefore the following holds: When a development process can be automated or made rigid (i.e. less prone to human errors) at reasonable cost (here lies the trick) it should be!
Confidence in one’s software
Extreme Programming refer to the confidence one should have in the software that is being developed. How true. It is vital to make sure programmers feel they are standing on firm ground. The verb “feel” is used not to suggest any kind of denial or masking the truth, but rather to the actual psychological state of the programmer. Some degree of inconsistency surely exists in the software and a programmer can undoubtly be unaware of some of it. Nor can a programmer be expected (by himself or others) to have a intimate familiarity with the all the dusty dark corners of the code. Yet he should feel confident to the degree that he will not resent or fear changes. Otherwise changes are likely to be deferred forever making room for ugly patches that are followed by a flok of bugs and yet another decrese in confident.
Confidence is the anti-patch drug.
To be continued…
Posted under Software development
17
October
2005
Note: The following paragraphs were written a year before I became aware of Joel Spolsky wonderful writing on the same subject
“What a mess, this has to be written all over again”—be suspicious (very suspicious) when you hear someone (possibly your inner voice) says a piece of code has to be rewritten. Most of the time it is a symptom of incomplete understanding of the problem at hand or of the code you are referring to. Assuming the original code was not written by a complete idiot (which is more often than not the case) you’d better give it another shot.
On the other hand the “if it ain’t broken don’t fix it” mantra is dangerous also. Wiser men (than me, ESR for example) said that sometimes you only understand a problem once you solved it. Often the first iteration of the code works, yet it offers a less crafted design than you want (and now know how to do) or an awkward interface that messes things in your code or a problematic implementation (inefficient, inflexible, not thread-safe) that imposes limits on its users. Rewriting it sounds like a lot of work, but refactoring it sounds like much less work (even if the two coincide) and is probably what you should do.
Experience (mine) shows that refactoring is a much shorter task than rewritting especially since you have less bugs to deal with (and they are mostly known) and the testing process is much easier (as you already have real users or clients of the code). It is comforting to discover that such refactoring usually pays itself (in terms of development time and debugging) immediatelly and therefore should not be considered a task for a rainy day but rather a routine task. Problems that are noticed today but deferred are not likely to disappear, so when a major design flaw or incomplete implementation is discovered and ignored don’t be surprised to see its agly head pop up in some lesser expected places.
Posted under Software development