Stop to think

Dave Thomas was in town stirring up all the geeks with his talk titled "Why Real Developers Embrace Functional Programming and NoSQL Data". I had a great time meeting some old friends, and hearing Dave cut through the crowd with the sharp tongue that he has.

His central message was to never stop learning.

Dr. Ivar Jacobson the god father of software components has lofty goals. He admitted being embarrassed by them last year, but now he's quite proud and loud about them. He was in Melbourne today talking about his latest meta-methodology SEMAT (Software Engineering Method and Theory).

• Academics don't understand the needs of industry. They have no practical experience within industry, so they pick a processes such as XP or Scrum to teach without a real need to use them themselves. Or they claim they are too proud to teach any methodology!
• Industry is wrapped up in many processes because they have a real need for them to deliver useful software. However, they aren't able to scientifically compare and choose processes - thus there are fads.
• Developers want to become experts in their domain, but find themselves lost every time they change jobs and have to re-learn a new process
• Methodologists have been prolific in creating fads, but have been unable to compare their methodologies in scientific terms.

To help them see eye to eye, Ivar has called to action some of the big names of the software engineering world who have created processes such as RUP, CMMI, Scrum, XP and many others.

Now until I get my hands on a full list of the 23 practices he has explained, I'm going to stay sceptical. I'm not going to say that software development is an art any more, but merely that it's complicated :-)

Here's an interesting idea for distributed computing when you have large amounts of data spread across numerous machines - move your code around (as ruby/scala/what-have-you continuations) instead of moving your data around. 

It's a research language called swarm:

http://blog.locut.us/main/2008/10/6/swarm-a-true-distributed-programming-lang...

http://code.google.com/p/swarm-dpl/

It's kinda like when you're in a library (the physical kind with heavy books, dusty shelfs and smelly aisles), and you pause reading a book to walk to the reference section to look up a word before walking back and continuing your book.

The coolest part is that most continuations can be contained in a single network packet - so there shouldn't be much network traffic bouncing around if you've partitioned your data vis-à-vis your problem domain.

I got up this morning and rearranged some energy to affect the world. That's what I do for a living according to Ron Burk -

I remember playing with gears as a kid and discovering some of their mathematical properties. But I never went as far as using cams to compute trignometric functions!

Watch these videos to learn how they used plain old gears and shafts to compute the trajectory of a projectile, and many other computations that the navy required.

Part 1 -

Part 2 -

Here's something new I learnt yesterday about the middle east - every house has a little indicator stuck on the ceiling pointing towards Mecca. My Emirates flight had a Mecca locator up on the projector every so often. Many people carry a Mecca locator GPS device on them. Every one is quite aware of the direction to Mecca as their primary direction.

All that orientation means that more people know the direction towards Mecca than the cardinal directions (N,S,E,W). This has some interesting implications for an application we're developing for here. We can't for example show a layout of a house and orient it to North and ask people to pick where they want their network points installed. People would just get confused. We have to orient our maps towards Mecca, or show a little Qibla arrow as they are called.

Someone did the leg work and found some real evidence about software metrics:

http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

The results are interesting, but not surprising if you've developed software for a while:

• "Code coverage is not indicative of usage" - Your hot spots need good code coverage, but not your cool spots.
• TDD projects take 35% more time to complete, but are 60 - 90% better in terms of "defect density".
• Confirmed that having more assertions reduces defects. However, you can't just mandate their use. Developers must have a culture of using them.
• Organisational structure matters a lot (herding your cats)
• Geographical distance doesn't matter much if your distributed team feels like they're working on the same team. Here's an interesting quote - <i><large>"Most people preferred to talk to someone from their own organization 4,000 miles away rather than someone only five doors down the hall but from a different organization."</i></large>

So why exactly is there a schism between computer science and the rest of the engineering world? It comes down to a fine red line according to this Doctor Dobb's Journal article:

http://www.ddj.com/architect/217701907 -