Month: November 2003

Software that Doesn’t Stink

Eric Lippert and Neil Deakin are discussing sucky software. Both make the point that one gets more tolerant of suckage in software when one has spent enough time actually trying to do software

“I failed to appreciate either of those facts until I’d actually done a lot of it myself. Once I appreciated these things, I understood that we have imperfect software BECAUSE the people who make it are dedicated to writing quality software for end users, not in spite of that fact.”

All I can say is that such excuses don’t make software suckage feel any better. Software tends to attract a lot of idealists, because software has the potential to provide large amounts of value for small initial investment. But, as Eric points out, writing software that is actually usable, reliable, and valuable involves all sorts of tradeoffs that affect the cost/benefit equation.

I’ve been involved with many software projects over my career, including IT, horizontal, vertical, and shrinkwrap. And although most of them shipped, and were considered “successful”, I have always been bothered by the disjoint between what I feel “should” be the cost/benefit and the actual cost/benefit results. We can invent excuses all day long, but at the end of the day I can never convince myself that these are anything other than excuses. I believe that there is tremendous waste in the process; far more waste in software than in other industries. This is why I don’t get too excited when people debate about whether Americans work too many hours. Especially in the software industry, the amount of overhead is so huge it’s a wonder we get paid at all. The idealist in me says that if people would slow down, spend more time thinking, engage in proper planning, and stop making excuses for the constant fire drills, we’d cut the number of hours worked in half. The extra hours we work are, IMO, evidence of the software industry’s high margins and tolerance for waste than evidence of any necessity.

To be sure, I’m not saying that poor planning and “fire drills” are the only source of the massive waste that I’m talking about. In times past when I led development teams, I took great pride in making sure that things were scheduled in a way that nobody was ever required to work overtime. But doing this is as much a process of padding the schedule for waste, scheduling in appropriately small discrete tasks, and so on. It certainly didn’t mean that there was no waste. While Eric may be right that developers tend to have good intentions, we have all sorts of well-known biases which lead us to have skewed priorities. Developers like to design for extensibility. Developers like to optimize the crap out of a code loop and ignore the database. And the list goes on.

We also have a tendency to consider ourselves to be better than we are. The developer who is optimizing the crap out of his code loop will look with scorn on the developer who doesn’t, while himself being looked down upon by the developer who has more experience to inform his scalability priorities. And once we have completely mastered a particular aspect of the process, we get promoted or bored.

And even when you have teams full of people who have tons of experience with development, project management, and so on, marketing (as in Marketing 101, not just advertisement) tends to be the high-order bit, and in today’s world that leads to lots of “strategy tax” tradeoffs and randomization.

In any case, this wasn’t meant to be a comprehensive list of the sources of waste in the software industry. Suffice it to say that I believe there are huge amounts of wasted human energy and precious little legitimate excuse other than the fact that software generates large enough return on investment that we tolerate the waste. The waste is systemic, IMO, and not something that’s going to be fixed with “XP”, CMM, development tools, or any other quick fix. For what its’s worth, I think that open-source is no panacea, and in fact is one of the biggest black-holes sucking away human talent needlessly these days. How many man-hours have been spent building a clone of the 30 year-old Unix operating system? There are many better areas for us to be applying talent. And I don’t mean to diminish the professionalism of Microsoft developers. The product teams here are some of the most well-tuned machines I have ever seen, but “best” is not the same as “perfect” or even “as good as possible”.

Who knows? It’s a tough problem, and IMO doesn’t get any easier to stomach with experience.

Dare, Deem, and Suge

Strangeness abounds. We are accused of smearing binary XML andpushingbinary XML in the same week, in both cases withinsinuation ofnefarious motive. Dare Obasanjo has the report.

Mike Deem has been keeping up his blog again, and it’s really good. I’ve hesitated mentioning it, since last time I got hooked on his blog he stopped for a year and a half to work on WinFS. If you follow any of the other MSFT blogs, you’ve already seen his comeback. And if you follow the other MSFT blogs, you probably didn’t have time to read that Big Lurch has been sentenced to life in prison. Consider yourself informed; yet more evidence that you should never, ever, evermess with Suge Knight.

Is InfoPath the Next Excel?

Larry O’Brien at SD Times asks “Is InfoPath the Next Excel“? He raises a number of interesting points, some of which I’ll try to respond to. First, he says:

“It would be easier to say “yes†if InfoPath were programmable from .NET languages. Not so. For some reason, InfoPath’s programming model uses Microsoft Script Editor, which supports only JScript and VBScript.”

It’s true that InfoPath uses JavaScript right now, but this is primarily an issue of timing. InfoPath was actually conceived long before .NET was around, implemented years ago, and much of the recent couple of years has actually been spent polishing the product to be a nice Office citizen rather than doing any drastic new feature work. And now that InfoPath is shipping, it is part of Office 11, which still relies on script code. So InfoPath is a very nice complement to the rest of the Office suite, and that’s how things get done inside Microsoft. Now, it is disappointing to people like me who have been doing .NET development for a few years, but there are still many Office customers who are more conservative and would probably be spooked if we required them to take dependencies on .NET to use Office. And finally, the next version of InfoPath is planning to support .NET much more fully, just as the rest of the Office suite will.

Next, he says:

“So the output of this new tool is available for programmatic manipulation, but far from the way that formulas and macros make the power of spreadsheets casually available, spelunking inside InfoPath form files is only for the stout of heart. No revolutionary power-user capabilities here.”

In fact, one key appeal of the InfoPath format is that everything is done using completely non-proprietary formats. The UI of the form designer is saved as XSLT, the code is all standard JavaScript, and the object model is primarily accessed using XML DOM. What this means is that I can design a form in InfoPath, crack the XSN, and copy the XSLT directly to an Apache server to use in generating HTML output (for example). Or I can borrow JavaScript that I wrote for my Netscape and IE web pages and use directly in InfoPath. And simple things are fairly straightforward, with no need to delve into code. I’ll grant thatadvancedworkrequires a stout heart — there are not many people who have expertise in the trifecta of DOM, JavaScript, and XSLT — but for those who do, the sky is the limit.

Anyway, Larry makes a number of other good observations which InfoPath-watchers may not have seen remarked elsewhere, so it’s good to read the whole article.

Simon Guest Sold Out?

Simon Guest’s book on J2EE and .NET interop is available now.Amazon claims to have only five copies left in stock, so you might have to hurry up, or else try Barnes & Noble.

WordML Schemas Offered

The Danish ISB has uploaded the schemas for Microsoft Word offered under a liberal license. Various people within MSFT, Danish government, and others worked very hard to make this happen, and it’s a very significant announcement.

The biggest news happened when Word began to support XML natively, though,and most people already had the right to create WordML documents dynamically from their own code anyway (because who doesn’t own a copy of Word?). But this is a nice step, especially for public sectors around the world.

For people who are not accustomed to looking at schemas, the new schema may appear to be no simpler than the RTF specs published for prior versions. But I would urge anyone who thinks so to “just try it”. I was able in a matter of minutes to write code to dynamically generate Word documents. You can do it in three easy steps: 1)create a template Word document, save as XML, 2) crack the file in notepad and 3) use the sample to drive your own code. I have been threatening to write an article for MSDN demonstrating this concept, but it seems insultingly remedial. Since XSLT templates are simply XML, you can even cut-paste a word doc into notepad, wrap with a few etc. tags, and you’ve got an XSLT that generates Word documents. Try doing that with RTF (I have, and it is very ugly).

Application Coach

Just getting back from PASS summit where I was trying to help out the teams competing in the application development shootout. A bunch of us from the SQL team have been doing shifts as “Application Coaches”, where we are supposed to be experts in the various technologies the teams need to build the application.

I had an hour, and only helped out one team. The team I helped had already been helped by Markand Arpanearlier in the day, and they were manually wiring up their Web UI to data using low-tech old-school technique of setting properties directly. I helped a bit with some ADO.NET and Web Forms stuff, and they were making great progress when I left.

On the other hand, none of us there could figure out how to help the two teams who were attempting to get ASP.NET databinding to work. Get the “hard way” working in ten minutes, and forty minutes of debugging fails to get the “easy way” working. It has to be something simple…

Sometimes a Dream is Just a Dream

About two months ago, I had a very vivid dream of losing a molar. In the dream, the tooth fell out and broke into multiple pieces. Losing a tooth in a dream is often a symbol of changes and growing in your life, and I thought of the dream in that context. When you are young, losing your “baby teeth” is one of the first really big milestones on your way to adulthood. Of course, when you are young, time is always your ally. You tell yourself that you’ll be bigger, stronger, smarter, more capable. However, you eventually realize that all time leads to death. Camus put it best, in Myth of Sisyphus:

“Yet a day comes when a man notices or says that he is thirty. Thus he asserts his youth. But simultaneously he situates himself in relation to time. He takes his place in it. He admits that he stands at a certain point on a curve that he acknowledges having to travel to its end. He belongs to time, and by the horror that seizes him, he recognizes his worst enemy.”

Anyway, thinking of these things a few weeks ago, I went in to have a crown placed on my molar. It was then that the dentist notified me the tooth could not be saved, and would have to be extracted. I scheduled the extraction, and two days before the extraction, a piece of the tooth broke off. Sometimes a dream is just a dream.

The extraction yesterday was rather painful and bloody. The roots of the teeth were determined to stay embedded in my jawbone, and the tooth broke into more pieces while being extracted. Losing a molar is something that the majority of people twice my age have not experienced, so I feel advanced. I am nursing a hole in my mouth, living on a liquid diet. When the jawbone heals in a few months, I’ll be installing an implant. Already I crave solid food, and am planning a trip to Vancouver in a few weeks where I intend to binge at Green Village, another Roland Tanglao discovery. Turnip cakes, pork dumplings; what could be better?

Ted Leung @ OSAF

Dunno how I missed this one; yesterday was Ted Leung’s first day working at OSAF. All I can say is that this is very lucky for OSAF, and now they stand a better chance of actually doing things right. I had similar feelings when they hired Rys McCusker, working on a similar area of the product, but Rys moved onshortly. Of course, I suspect that Chandler will one day compete with Outlook (despite their protestations to the contrary), so I have mixed feelings about them attracting and retaining talent. But competition is a “good thing”, and for Ted’s sake I hope they keep him happy.

Storyboarding UI

Today I am mocking up some UI storyboard. This is one of the fun parts of being a PM, and something I don’t get to do much since my group is concerned mostly with API design. The last time I did any intensive storyboarding was when we were designing XQuery Builder, which we showed at PDC. Different groups in the company do things differently, but here’s my process:

  • Mock up the basic outline of the form using VS.NET designer and run it
  • Alt-PrtSc to capture the UI
  • Paste into Windows Paint
  • Draw text, screen grab from Excel for grids, etc.
  • Save as a GIF
  • Create HTML hotspots for buttons and other regions
  • Set up HTML pages and hyperlinks to connect all of the screens

Depending on how you do this, it can look deceptively realistic when you walkthrough the “application” in a presentation. I also think this approach is appealing, because it forces the PM to focus on the user interaction model rather than screw around with trying to prototype the app in VB or whatever. Obviously, some things like drag-drop (which we used extensively in XQuery Builder) are not well-suited to this method, but I think it’s a lot simpler than using Macromedia or something to mock the UI.

~

An interesting DHTML behavior; allows binding to XML as a data grid.