Why I did not buy a Samsung tab...or an iPad

Last Saturday, I walked into an electronic store to purchase a Tablet, a tab. My preference was for the Samsung 10.1; in the store I also came across the iPad 2. And in this section was also on display an array of laptops.

Why do I need a tab? My usual practice is to surf the net after dinner, possibly read an e-book, catch up with people on Facebook or LinkedIn. I do it on a laptop connected to the net through Wi-Fi, sitting at a table in the living room. And I doze off most of the time. It would be so much more comfortable if I could do all of these propped up in bed, and doze off without a care.

The Samsung 10.1 on display was a 3G+ Wi-Fi 16GB version priced a little over Rs 33,000. Its cover, a necessary accessory, was an extra Rs 3,500 or so. Which meant that the tab would cost me between Rs 36-37K. The 3G+ Wi-Fi 16GB version of the iPad2 with cover was Rs 37,000. The one with 32GB was around Rs 41,000.

At this point I began to wonder if, at this price, it made any sense to buy this device. At a price of Rs 40-45K one could purchase a much, much more powerful laptop with oodles more hard drive space, and do more on it than is currently possible on a tab. [Don’t believe me? Check out the Dell Vostro 3750 which sells for about Rs 41,000 all inclusive.] And of course, any worthwhile laptop can connect to the net through a Wi-Fi connection, or a wireless device from your favorite mobile service provider, or can be tethered from a 3G phone. So what would I miss? The touch screen for one, its light weight, and certainly the convenience of surfing or reading propped up in bed.

Didn’t I know all this before I visited the store? I guess I did, but the heart went like “Let’s get one, let’s get one”; and it was only after we actually fiddled around with the tab that the head asserted “Come on. This gizmo is not worth 37K. A 40K laptop is more value for money any day. Get a hold of yourself. You want to spend 37K so you can surf lying down, and push things around the screen with your finger? Shame on you!” The heart didn’t have an answer.

So I am back at my laptop. The heart is disappointed. And so is the head. This innovation did not match up to expectations; or perhaps it wasn’t created for me.

Weird Architecture

Sometime back the technical consultant of a customer accused me of having created a ‘weird architecture’ for her project. And this after we had completed an iteration that met agreed goals, work which was commended by the customer as ‘brilliant’.

This was a Web 2.0 application, built on the ASP.NET framework, written in C# and targeted the .NET Framework 3.5, with a SQL Server 2005 database, and hosted on IIS 6.0.

So what was ‘weird’?

The project consisted of several web applications and was deployed on the IIS in the manner shown in Figure 1. A web site was created and web applications were deployed as virtual directories under this web site.

Figure 1

A separate Application Pool was created for this web site, as indicated in Figure 2.

Figure 2

From the above example, Application1 could be accessed from the URL http://www.myapplication.com/Application1 and so on.

In the past few years, I have come across several applications which have been or will be deployed in this manner. What was/is the motivation for deploying the applications in this manner?

We analyse this through a couple of case studies. Read the analysis here.

Great People, Great Teams

Bill Taylor’s post Great People Are Overrated on the HBR Blog Network has generated a lot of heat. His post was triggered by a statement Facebook CEO Mark Zukerburg made in an interview: “Someone who is exceptional in their role is not just a little better than someone who is pretty good,” he said. “They are 100 times better.” It emphasised what Marc Andreessen had told him: “Five great programmers can completely outperform 1,000 mediocre programmers.”

Bill Taylor does not agree with them. He goes on to make a case that a team of average performing individuals is better than high performing superstars, and concludes: “Most of business life isn't really a choice between one great person and 100 pretty good people, but if that is the choice, I'm not sure I'd make the same choice as Mark Zuckerberg — especially if those 100 pretty good people work great as a team.”

The last I saw, his post had received 272 comments, mostly from software practitioners, and the majority pilloried him.

The software devlopment crisis

Some blunt observations on the state of software development practices today, and a way out.

See other Tech-Ed 2011 videos here. Of particular interest to me were those tagged as Development Practices and Architecture.

Shrink a SQL Server database

When we create a SQL Server database, it is created with a full recovery model. This grows the transaction log (the .ldf file) with every transaction we make on the database. Usually the size of the transaction file is many times more than the .mdf file.

If not maintained, the transaction log would eventually fill all the disk space that is available to the physical log files.

In a development/ testing environment, when the data is not important, the transaction log is not important. It is a good idea to maintain the database with a simple recovery model.

Run this command in the Query Analyser to change the database to a Simple Recovery model:
ALTER DATABASE [<DatabaseName>] SET RECOVERY SIMPLE

Run this command to reduce the size of the .ldf file:
DBCC SHRINKDATABASE ([<DatabaseName>], 20)

When deploying the database to production, turn it back to the Full Recovery model:
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL

Replace <DatabaseName> with the actual name of the database.

Read more:
MSDN Books Online: Transaction Log Management

Why I am bullish about India

A wonderful article by a friend that sums up the soul of India. Read it here.

Bugs!!

From Three Questions About Each Bug You Find
"..Do you sometimes fix a bug, and then find another bug related to the first or to the way you fixed it? When I fix a bug, I ask myself three questions to make sure I've thought carefully about its significance. You can use these questions to improve productivity and quality every time you think you've found and fixed a bug..."

Figure 1

Figure 1 is "The First 'Computer Bug' Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1947. The operators affixed the moth to the computer log, with the entry: "First actual case of bug being found". They put out the word that they had "debugged" the machine, thus introducing the term "debugging a computer program". In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia, which erroneously dated it 9 September 1945. The Smithsonian Institute's National Museum of American History and other sources have the correct date of 9 September 1947 (Object ID: 1994.0191.01). The Harvard Mark II computer was not complete until the summer of 1947..." The First "Computer Bug"