Is web usage a distraction?

I recently started a study into how people use the web at work. It got picked up by PC World and a few other companies today. It is the first in a series of articles.

PC World Article is at http://bit.ly/cFrx2A

Do up vote on Reddit if you find it interesting http://www.reddit.com/tb/btyw6

The report itself is currently behind an "email address" wall since it was sponsored by a commercial organisation. The interesting aspect is of course the technique used to mine the data and how we arrived at the conclusions most of which are not discussed in the PC World report. One of the outcomes of this venture should be a browser plug-in (in time) that will measure the distraction and profile monthly usage allowing people to adjust their behaviour if they choose to.

What is the difference when compared to the many other tools out there? Rather than just attempting to dump a table of top sites with charts and timers, I am attempting to first observe the users behaviour (over some time) -- then build a pattern template and watch if this behaviour pattern changes. The approach I am taking is to see if the behaviour is changing slowly over time -- and if there are sudden changes.

Obviously, most web users may not directly care about this information, but employers are keen to find effective methods to integrate web use at the workplace. This is the area that I am hoping to make some impact. The web will be around -- it will be used at work -- lets hope that sensible policies are developed to use the web, rather than put in strict regulations based on a few exceptional events. To provide some balance we need good data to inform policy.

Strange as it may be, my experience has been that policies are often developed to compensate for some exception (that is they develop policy for that "one" person out of 1000 that spends a bit too much time on Facebook). If policies are not properly regulated by using good empirical data, over time the policies will eventually be outdated -- inflexible and get to a point where they are going to be silly and even dangerous.

The web will be around for a while -- it is going to be used at work wisely by the majority, and poorly by some. This is to be expected. I am hoping that we can improve the quality of the feedback loop so that people can make adjustments to their web usage themselves.

-- rv

On Integrated Development Environments...

I was asked an interesting question recently -- "What is the minimum expected functionality in an IDE? (for me)". This was part of a broader discussion related to what functionality belong's in the "core" of a product.

----

Here is my answer -- let me define a bare-bones IDE first: A program that should allow user to -- Type code + Build/Run programs + Jump to line from compiler output if needed + Jump to line from stack trace (if one gets generated).

Now for the minimum set of features/functions (in no particular order)::

1. Syntax highlighting (bold keywords would be minimum, prefer colour highlighting)
2. Jump to method body from a method call -- including methods in another class (F3 in Eclipse)
3. Code completion
4. Multiple tabs (not many -- but 4-5 buffers is sufficient)
5. Short-cuts for open/close files/tabs, to compile, run, navigation, code completion.

I have intentionally left out a whole bunch of things that many others would consider critical, so let me explain my rationale::

• Project resource organisation (src, lib, dependencies etc): I prefer these in an external build script. As long as the IDE allows one to invoke this external build script via a short-cut then it is sufficient. Build scripts are also handy in large team development.
• Code folding: Never really used it in Java/C#, will not miss it if they yanked it out. I have used it a bit when digging around some large XML files (which I am certain was required due to some serious bad karma in my previous life -- I have learnt my lesson now, so all will be well by my next birth). Probably handy for HTML developers, but I can live without it.
• Project file tree view: Handy, but the OS provides file explorers. When a good command interface is used properly, I can get to the code file pretty quick (i.e. Norton Commander like UI -- muCommander these days).
• SVN/Git integration: Happy to switch to another application that specifically is designed to do this well rather than load a slow buggy plug-in inside the IDE. It is nice to have the intelligent "diff" inside the IDE, but to me it is not a killer feature -- and I can use it quite effectively outside of the IDE.
• Defect repository integration: Again, prefer to use an application that is specifically designed for this task.
• Debugger: Necessary tool, but not "core". You see, I am an optimist (and far too arrogant to admit that I would ever need a debugger). Well they did invent printf so that developers can avoid using the debugger.
• Models/UML/Program visualization: Models are better on a whiteboard. We can get UML reverse engineered if pretty pictures are needed in a document (or) for more rigorous communication (i.e. forced on me). Program visualisation? Handy if I am new to a code base -- but they are not my type. Forward engineering from UML? Tried that relationship too, did not work out, so we broke up. My brain seem to work better and faster in code than in UML.

As you have probably guessed by now .. my preference is to have a bunch of small applications that are built to increase productivity in a specific task. I do acknowledge that there are many tasks that developers do as part of their work-flow. But, the issue is "how often" we do some tasks. Compared to cutting code -- the rest of the other tasks, in general, take up a lot less time hence I prefer these out of the IDE.

I am a part-time developer these days -- so the question is I am missing something that full-time developers consider critical?

Scheduling in software projects...

Next week, I am giving guest lecture on "Scheduling in Software Projects" -- hence this blog post reflecting on where I find it hard when managing real-world projects (as well as even student projects).

I will start out with stating the obvious -- "scheduling in software projects is a hard problem". Why hard? Simple ... almost all (simple) scheduling techniques are based on two weak assumptions:

1. We can estimate how long a task will take (minimum time -- maximum time).

2. These estimates are reasonably stable (say for at least 2-4 weeks -- this implies the task specification is sufficiently clear, and the developers have the knowledge+skill and technology to complete the task)

These assumptions are the crux of the problem because we cannot estimate well and task specifications are often fluid. But, there is some good news -- developers often can improve the accuracy of their estimate once they start working on a task (even when it changes a bit), and this estimate gets better the longer they work on a task uninterrupted.

Here is an analogy for why estimation in software development is hard:

"You are asked to translate a sci-fi fantasy book from French to English. But, the author of the French edition does not have a complete story nor has she fleshed out all of the characters fully. She has completed about 50% of the book in French and wants the English translation to start soon, so the publisher can release both books at the same time". Can we estimate how long it will take to complete the English edition? Well, how about if we got 5 English writers to work at the same time? Would you like the job of managing these 5 writers -- and produce a project plan against which you have to give a weekly status update?

The analogy is a tad crude -- but it is about as close to software development reality as it gets.

-----

There is another side to the scheduling story. A vast majority of software development work involves extending and maintaining a software system. Which makes scheduling hard since we never know who will be needed for other higher priority tasks. Why can cause a higher priority task?

Well ... the short answer is: bugs! + meetings (sad, but true) + emotions (random interrupt that will pre-empt all other functions in the brain -- esp. strong in meetings).

We cannot estimate how long it will take to fix a bug easily -- Why?

1. Well the developers have to replicate the bug and find out it is a bug --> It take some unknown quantum of time > 10 minutes (why 10? Glad you asked. Over the years, I identified that it took me, at a minimum, 10 minutes read a defect report -- complain about it being very poorly written -- replicate it -- write up a brief note either acquiring it for investigation, assigning it or closing it).

2. If it is indeed a bug, identify root cause. --> Will take over 10 minutes (why 10 again? Well... one has to check out appropriate version from repository, compile and pray that all goes well, reluctantly run in debugger, find culprit and court martial them, got through a mini-localised-merge nightmare, check-in code with appropriate comment, update defect tracking tool, update time tracking tool, check Facebook, write a comment on Reddit, read twitter updates, complain to the world on twitter about the sad state of the codebase).

3. Integration + Regression testing. --> Pick a number > 1 (trust me -- it will be at least 1 minute).

In a perfect world, it will take a minimum of 21 minutes per defect (maximum or a realistic time to fix and evaluate ripple impacts are completely unknown).

Bugs are relatively easier to work on ... but, "new features" and "requested enhancements" these are a completely different ball game when it comes to estimation. Why? Well, since we now are entering the world of "serial meetings" and "wonderful emotions". It is sufficient to say that even the most trivial enhancement is likely to translate into a time quantum > 1 person hour/feature (really? minimum of 1 hour? Well the tasks will involve at a minimum -- thinking/spec + analysis/high-level design + programming + unit test + merge + integrate + regression test + emails + release notes + discussions + arguing why the feature is a good idea + arguing why the feature is a dumb idea + complaining to the sales/marketing team that they should ask before selling a dumb idea + staring blankly at the walls).

----------

Alright .. so estimation is hard, which makes scheduling difficult. So, why bother? Why should one even attempt this? If you are still reading .. thank you for hanging in there. Here is the reason....

We create a plan in order to "prepare the development team" and only hopefully to follow it (i.e. sticking to the plan is a bonus and can happen if the stars are all aligned in the right quadrant of the sky). The entire exercise helps the team consider the issues involved and you are very likely to get the "minimum time it will take" reasonably correct. My experience is that the "minimum time" gives the clients a sufficiently large heart condition.

I find planning exercises are useful if the team collaboratively develops it and reflects on it regularly (every 3-4 weeks works well in my experience). It improves productivity (indirectly), helps team communication a bit better (at least you know what is going on), and allows the team to get a big picture overview and provides some sense of the business drivers/pressures.

However, the fastest way to kill morale and productivity in the development team is to actually force them to stick to some "schedule" that was developed early in the project life cycle by the "all seeing management".