Easily Bored

The NY Times article on productivity [reg required] is getting a lot of attention. I have suffered from what I feel is rapidly diminishing productivity in recent years, some of which I believe is due to constantly divided attention. I was turned onto getting things done simply because I felt like I wasn't.

I think it comes down to people continually, progressively becoming more easily bored. In lives with constant stimulation, applying the focus required to get something done, something less stimulating than trying three things at once, seems boring. I think of the tv screens with multiple tickers. Dashboards. There is a definite need to find ways of creating ambient alerts. Things that only interrupt us when they have to. I think ambient findability is great concept as well. If I am typing in a document, and relevant resources on my hard drive, my network, my email, and the internet are being updated in a sidebar, they will be right at hand when I decide I need to look for something, it will have already been found.

There's so much to do. How can we be so bored?

Why are people such bad estimators?

Why are people such bad estimators?: "Painters say 5 days, it takes 8. Designers say 2 weeks, it takes 4. Programmers say 3 months, it takes 5. Government says it will take $X and it takes $XX. It’s been a very rare occasion (in my life, at least) that estimates have been anywhere near accurate. Even people in business for 20 years seem to have a bad time making accurate estimates. I realize an estimate is just a guess, but there’s a lot of bad guessing going around. What is it about people that make us such bad estimators?"

I think this idea has been around a long time- here's some top reasons why we're bad:
1) Humans are too optimistic.
2) While it may be possible to estimate how long it would take to do something if everything things went right, it's often difficult to estimate with error, interruptions, etc. that you don't have good data on.
3) What type of date is being given? What is a 5 day estimate? Is it the earliest date something could be possibly finished? Is the 50-50 date? The 90% date? You are talking about something that is stochastic, and would occur in a distribution.
4) The future does not always work in the way that the past did

And what to do about it:
1) Stop estimating
2) Adjust estimates based on progress (running features in a software project)
3) Present estimates as a probability distribution.

You don't complete me.

Setting up a Rails Development Environment on Windows Using Eclipse
Heading says it all really. I have to say that code completion for non statically typed languages is something that I am seriously missing. Having first tasted its lazy goodness in Visual Studio, I was aching for it to be supported in Java forever. Now, I have to wait again for Ruby. I have heard rumor of code completion in JavaScript. I haven't tried that yet, but I can't exactly imagine how it's going to work.

I think the best thing about code completion is not that it obviates the need to memorize tons of stuff, is that it reminds you of methods that exist on objects that you may have forgotten about. Maybe there is some kind of inbetween thing so that I can at least specify what type of object I want to be dealing with and get all of the methods and properties presented to me for easy clicking. Maybe I should be working on this...maybe not.

Remember the Milk: More TODO

Remember the Milk: More TODO: "We must be getting really organized with all of the TODO list applications that are springing up. "

Remember the Milk
I can't decide if this is better than the free version of basecamp (one project limitation). It seems to have a couple of subtle bugs in the ajaxy aspects, but it is definitely a cool interface. It has the feature of sending email to add tasks, which works in backpack, but not basecamp (perhaps due the complexity of determining to which list the task should be added, which Remember the Milk solves with an inbox). I also like getting SMS messages or emails to my mobile when something is coming up. Anyway, it's good to see more apps in this realm. I think calendar integration is key. I need to find a good way to sync these things to ye olden blackberry until I get a more advanced mobile solution.

Falkands vs. Malvinas

Falkands vs. Malvinas: "A confusing and confused article in the UK tabloid the Sun states that 'the British islands in the South Atlantic have been given Argentinian place names on the interactive Google Earth site.'

Well, in Maps the Spanish names are appended in parentheses. I have no problems with that, as it makes the map more useful to finding the islands when cross-referencing from other (Spanish-language) sources. (No access to Earth right now so if somebody could check...) "

It's interesting to see the reaction of people getting exposed to GIS data. The names of places can be very political. When I was giving a presentation in Morocco, they were disappointed to see that a country list in our application included "Western Sahara", which they rightly considered to be part of Morocco. Of course, we had not reviewed the list- it was an ISO list of country abbreviations.

To blame Google for any of these errors is idiotic- the data providers are the ones who made the decision, and they probably based on a list provided by an international standards body. While the name of place may seem to be the endorsement of a political belief, there's really no good way to be neutral and put all of the possible names for a place on a map and remain cartographically accurate.

This problem is doubly difficult when you are trying to produce a map for worldwide consumption. Do you call it Germany or Deutschland?

Joel- Agile Again

October 12, 2005:
"(The nattering scorekeepers of the BDUF/Agile beauty contest are now thoroughly confused. "Was that a vote for BDUF? Or Agile? What does he want? Can't he just take sides for once?!")"

Given that this method is almost word for word what is done in Planning Extreme Programming, I would say this is Agile. :-)

Big design up front isn't just about designing all of the features at once, you could still slip into doing iterations that are too big. And you could do 50 pages of UML models for a small iteration as well.

Rails =? Database-Driven

Playing with rails, one might note that it seems to be primarily database driven design (vs. domain driven design.) Why not generate the tables versus generating the model? There must be a good reason. I think the active record pattern is limiting for domains with complex structures that are best suited to object oriented design (whatever that means). While relational databases have some powerful features, they just aren't as good from a team/development, code maintenance perspective.

Service Oriented Gridlock: Code Reuse vs. Service Reuse

One of the oft mentioned advantages of SOA is that it provides a clean mechanism for code reuse. However, this is not strictly code reuse. In SOA, the reuser is reusing the actual running service. In code reuse, I take your library and embed it in my application. In service reuse, I call your live, running service from my application. In code reuse, if your application crashes, or the whole project is cancelled, there is no effect on me. In service reuse, I am entirely dependent upon the performance characteristics of your application. Think about the interdependencies ofa few three nines (99.9% available) applications- the availability of all of them drops. If one dies, they all could. Therefore, the "code reuse" argument for SOA is completely spurious. That's not to say that applications should never be integrated, but it shouldn't be done simply to reuse code.

The standard SOA response to dependency is indirection. In order to not create a hard dependency on your system, I use a third system (a service registry or directory) to look up the physical address of a service that offers the service your system provides. However, in your streamlined SOA, you have probably eliminated redundant applications, so there is nothing to switch to when your app is down. And now I am dependent on the service registry as well.

I am quoted...

http://informationweek.com/story/showArticle.jhtml?articleID=171000746

http://www.computerworld.com/managementtopics/outsourcing/itservices/story/0,10801,104841,00.html

http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=171200249

http://www.fcw.com/article90881-09-22-05-Web

Enterprise Architects should work on real projects

Martin Fowler has a link to Rebecca Parson's article on Enterprise Architects staying connected to development teams. This is an important thread of meaning in my thoughts on Service Oriented Gridlock- and the danger of the false architectures. My theory is that CIO groups, such as enterprise architects, should submit requirements to projects, and fund requirements to projects, such that they are prioritized along with other project requirements, such as ones actually requested by customers...