Thin (thin) client

Seems like something Sun should have invented years ago.. An all-in-one device that is wall mounted, and is supposed to be used as a thin client PC.

Tracking issues with check-ins

Here's a "best practice" I have come to believe in. Those in the Agile camp might consider it heavy handed and beuracratic. I think it is a heathly compromise that bridges the gap between development groups that "go dark" for extended periods of time, and project management practices that micro manage development's work.

As part of the code line policy (which should state how/when developers check-in their code to a particular branch’s code line), require that developers include the bug/issue identifier as part of their check-in.

I’ve done this in the past with good results. There are a few subtle and positive side effects from this practice (even if entry of the issue number is completely manual):

• The combination of an issue tracking system and source code control, in which the check-ins are linked to the issues, is what pushes source code control over the edge into true Configuration Management. The key characteristic being the issue/task management as an abstraction that sweeps up many different change artifacts into a “fix”, “feature” or other discrete package of work. The practice provides the ability to consider groups of check-ins as an atomic unit of work downstream. This is useful in troubleshooting regression, tracking progress, and packaging/release.
• Developers tend to check-in code associated with a specific unit of work (assuming the issues outlined in the issue tracking system are appropriately granular and discrete). The benefit being towards Continuous Integration—in which the code line progresses towards an end state with steady, stable, and identifiable improvements.
• When developers don’t have an issue associated with the work they’re doing, it highlights informality in their work queue management. This path is wrought with landmines, I know, but can be navigated with success. In my experience the delta between a healthy and practical task tracking strategy and fantasy is only dealt with when it affects the developer’s day-to-day activity. The litmus test being how well the issue tracking system reflects the group’s consensus of reality.

This practice becomes most useful when the issue tracking system can handle more than just defects. For example, when requirements decomposition manifests itself in the issue tracking system as “new feature” issues, or other issues are broken down into “subclasses” from the issue generalization:



This model allows developers to check in code against a generic “issue” number in the issue tracking system, yet each of these issue types can advance through their own lifecycles and workflows (which they should). Ultimately the configuration of the system is identified as a set of issues and their related change artifacts (the point being, to release the right thing for the right reasons).

This is why a lot of the high-end CM tools provide both a Source Code Control system and a Bug Tracking system. When you buy both from the same vendor, you buy all the hooks required to associate issues with check-ins. Unfortunately, this ties you to a particular issue management, source code management tuple. I would prefer to combine best-of-breed in both.

I have some experience doing this with Atlassian's JIRA and CVS. I think I'll write up the blow-by-blow of that implementation in another blog entry.

Information Radiation

This article is not quite a classic (it has a lot of esoteric language and concepts that reduces effectiveness and applicability), but still thought provoking treatise by Alistair Cockburn entitledAgile Software Development: Forming Teams that communicate and Cooperate.

In this article, Cockburn describes something calls "Information Radiation" under the section on "Convection Currents of Information." This is a useful concept. I can visualize the sources of information (such as a common whiteboard) literally radiating information to those who walk by. As somebody who's now tasked with the development of collaborative tools to support software development, the idea has a lot of applicability to tools such as project management (how to radiate priorities, status, etc.) as well as critical technical indicators such as the state of the nightly build or automated testing results.

Steam and mechanical engines

Funny how things come in waves on the Internet. This morning it seems that steam and mechanical engines are making the rounds.

Several links just today:

An index of animations of various types of engines.

A link to a site that sells (relatively cheap) kits and assembled models of Forest Engines.

A MAKE blog on How to make steam engines.

Oracle to offer free (limited use) version of 10g database

Oracle is offering a free version of the 10g database. It is called Oracle Database 10g Express Edition. The database does not appear to be crippled functionally, but is limited quite a bit in how it can be deployed:

• Supports up to 4GB of user data (in addition to Oracle system data)
• Single instance only of Oracle Database XE on any server
• Only uses and executes on one processor in any server
• Can use up to 1GB RAM
  

A quick download and a short trip through a real Windows installer (No more OUI nightmare?) and you've got a running Oracle database in about 10 minutes. Regardless of the licensing model, getting people to download/install the database and removing barriers to doing so is probably the smartest thing going on here.

The Sky in a Room

Digg.com dug up this cool old article on how to make a Camera Obscura using one window of your bedroom. Certainly the kind of science experiment I'll need to do with the kids.

Weblog Usability: The Top Ten Design Mistakes

I've thought about this subject a little. Whenever I'm considering the title for a post here, or how I should describe the link text in a post. But since I think there's roughly two people who might read what I post here, I don't think it's worth a whole lot of effort..

Jakob Nielson's recent article on Weblog Usability: The Top Ten Design Mistakes. Points out some good rules that I hadn't thought of. My favorite is "Forgetting That You Write for Your Future Boss." I wonder how many people will regret what they have to say in their blog some day.. Or how a smart person could create an entire persona of themselves that's not quite accurate, and tip off potential employers to their blog.

Apple & Blogs without RSS

Being a wannabe Apple Zelot, I am facinated by this "new" blog by a former marketing exec at Apple. My only complaint--blogs for which I have to hunt for (or worse, not find) the RSS feed.. I have to use http://reader.google.com to read this stuff--or I'll never come back to it..

(as an aside, http://www.digg.com seems to be pretty good so far too..)

SCM Explained (Finally!)

When I monitor some of the SCM related blogs, I notice a trend--seems like the low guy on the totem pole is always the one who gets stuck baby sitting the SCM effort. That's too bad because good SCM is important to any large (or growing) software group. Especially when you start thinking beyond how to design/construct a product and about the complexities of release management. Unfortunately, there tends to be two types of materials out there on the subject. One is vendor propaganda (or at least discussions about SCM in the context of very specific vendor tools), the other is too basic and cursory to be of value in the real world. There are certainly sites out there dedicated to the subject. But they're often inundated with vendor specific information that obscures the general patterns and knowledge necessary to ground yourself in the subject.

I've come across a few really good resources over the years. With the discovery of a new article the other day, I think I can put together a decent "study plan" that covers a lot of SCM scenarios.

The first is an article that lists High-level Best Practices in SCM. This article assumes you already know some of the mechanics of SCM. (Granted, *I* assume you already know at least the basics of using tools like CVS or VSS). However, this article grounds you in some important principles.

The second thing to read is Advanced SCM Branching Strategies. This is a fantastic article--I wish I'd discovered it a long time ago. It dives deep into the subject--yet still provides some concrete strategies.

Finally, Streamed Lines: Branching Patterns for Parallel Software Development has been turned into a book entitled, Software Configuration Management Patterns. The web site is a great resource, but the book contains a great deal more information (and I think consolidates the sprawling form of the web site). I recommend reading the book, and bookmarking the site.

Why they're all short term jobs now..

I now work for a successful local company that has made it's way to the top of a discrete manufacturing niche. Over the past several years they've started down the software path. They developed one software/hardware system and are in the process of developing another. There's one problem: lack of local talent who can do the software work.

Hiring has been slow despite the best efforts of the company. They go through a lot of trouble to convince people that this is a good place to live/work. But they can't control the fact that there are not a lot of high tech jobs in the area. And that's the problem. Software people tend to move from job to job every once in a while. While in manufacturing you might hire an employee for the long haul, in software employees need other job options in the area before they'll work for you. It's not that we're flaky (although, we are), it's because the technology evolves so fast. In 5 to 10 years this company might still be manufacturing its hardware in pretty much the same way it's doing so today. But in 5 to 10 years the software systems we're developing will be completely different. We may need a completely different set of skills from our developers. During all that change, people will move on. It's a fluid environment.

I was reminded of all of this by this article about using large arrays of small antennas to talk to spacecraft. When I worked at JPL for a few years, I had a chance to work with some of the folks on the Deep Space Network (DSN) and marvel at the giant antenna they used to talk to their deep space craft. Certainly the laws of physics aren't going to change enough to obsolete these huge antenna? Well, times change..

Funny how fast these kinds of things happen

The video iPod has been out for two weeks, and people are already hacking the thing in interesting ways..

Blue Marble

Some neat links from slashdot:

BlueMarble is a series of NASA earth images. These have some stunning resolution and processing that allows you to see the earth as no human has seen it before.

Celestia is planetarium software that lets you leave the planet--or even the galaxy. A couple of interesting things to do with Celestia: View the demo from Help->Run Demo. When the demo is done, choose Time-10x Faster. Select this several times until the Earth is really spinning.. Then choose Render->View Options.. and turn on all the options. Pan around the solar system to get a good idea of what a busy place it is. Right click on interesting objects and choose "Goto" to zip from body to body.

Are you selling your hours, or licenses?

Joel on software sums up nicely the issue of custom software development vs shrink wrapped software development. Personally, I've never seen a software shop that didn't struggle with this issue. Maybe because I've never worked in a software company big enough to be well insulated from customers via a big pile of cash. Or maybe because software is so "soft" it only makes sense that the sales people should promise something you're not tooled up to deliver.. In my experience, both as a consultant and as a vendor of commercial software, two things people said to me stick:

In the context of custom software: "Do you really want to sell your hours for the rest of your life?" Meaning, you need to get some people working for you if you're going to make a good living in that market.

In the context of commercial software: "We make money by selling licenses, not software." Enough said. Shrink wrapped software product strategy needs to be brutally honest about what you're selling--because the money's to be made stamping out identical CD's and selling a document with a license number on it.

they're important high level principles to keep in mind, regardless of your business model.

Less is more--I mean it this time!

I'm happy to report a trend in software application and product design. Simplicity. I've got three examples of successful product types that are not just successful, but winning market and mindshare:

1. The iPod (and the new generation of Macintosh too). I covet my wife's iBook. It's easy to use, powerful, and has all the right tools in all the right places. It can't make life easy enough for her to set it up on our home wireless network with WEP encryption, or set it up to use the HP photo printer hanging off our Dell PC in the closet--but it certainly makes my life easy when I'm tasked with those sorts of issues.

Likewise I didn't know how inviting and fun to use my iPod was until I started trying to navigate and use my Delphi MyFi XM receiver. The latter device has about 50 buttons on its front and I use exactly zero of them. That's right--in the past week I haven't touched a single button on the front of this device. Rather I use the scroll wheel on the side to change channels (and the power button on the top of course). The advanced features provided by the buttons on the front of the receiver may as well not exist. If only Apple made an XM receiver.

2. Google's products. You'll notice a common pattern with Google's "service of the day"--it doesn't have a single feature that isn't necessary. I'm sure there's lots of AOL and MSN folks out there who simply declare Google's new tools devoid of the critical mass of features necessary to make switching worth while. But if you use these tools you realize that the features you really need are all there. They may just be neatly tucked away behind a UI affordance that is so obvious it's hard to see at first. Just as the first Macintosh threw people off because there was no "eject disk" button (rather, you dragged an icon of the disk to the trash can), new users to Google's services might be thrown by its simplicity as well. How do you reorder the layout of a personalized Google home page? You drag the areas on screen where you want them--that's how.

3. Stuff from 37signals (and the Ruby On Rails cult underneath). Visit 37signals and you'll see a handful of simple, sexy applications that, as an MSDN author on Coding4Fun said:

But sometimes less can definitely be more. Enter a small company made up of five individuals that understands this very well: 37 Signals. They've successfully launched three VERY SIMPLE online applications that have made them nearly legendary in the web development community. The secret of their success: carefully targeted applications that leverage cutting-edge technology to make collaboration intuitive through absurdly clean and simple user interfaces that anyone can quickly and easily use. Couple those strengths with a "first hit is free" marketing model to compel users to upgrade to paid services for improved productivity, and it's not hard to see why they've done so well.

You'll find the 37signals apps look and feel an awful lot like some of Google's newest applications. For example, hover over a note on a Backpack page and the edit button materializes into view on the left. Move the mouse away and the edit button goes away.


These products have something in common that make them successful:

1. A razor sharp focus on a specific customer demographic and associated use cases. These are not "kitchen sink" apps that are designed by committee with globs of compromise piled on top. They're highly focused applications. A beneficial side effect being time to market..

2. Easy to use, inviting, good looking, clean user interfaces that support all of the requisite functionality, without clutter and confusion.

These kinds of products (certainly Apple and Google) are dominating the hype market these days. I hope this reflects a coming of age in terms of product design going forward.

Holding developers liable for security flaws

A recent story on ZDNet quotes a security consultant as saying that developers should be held liable for security flaws.

Seems to me that an employer should certainly make developers accountable for the quality of their work. And without the proper oversight, management and practices, poorly organized employers will quickly run out of qualified employees. But it's the entity that is selling the software or service that should be held liable.

In general, this article reminds me of just how haphazard so much software development still is today. I've seen many commercial products that were developed by whatever means seemed to work at the time. It's still the wild west out there.

IBM to donate "RUP" to Eclipse Foundation

A lot of words here that say pretty much nothing about the announcement by IBM that it will donate portions of RUP to Eclipse Foundation. But it's the thought that counts..

I've struggled over the past few years to find a methodology that management can understand and accept, yet is well documented and thorough enough to actually work in the real world. The best I've been able to come up with is a smattering of best practices here and there. Certainly most software shops have unique needs that prevent a "one size fits all" attitude towards methods. But like software architecture, there are patterns that typically apply--and it is possible to define frameworks and scaffolding that can be quickly deployed to bring value. This is a big part of Agile's success. It is simple enough to understand and can be articulated in practical terms to be immediately useful. The problem with Agile is that it still embraces enough art and artistry that management struggles with it--not all development shops are trusted enough for agile to succeed.

I hope that "RUP-lite" has enough of the important elements, and can provide the important tools and techniques that the patterns begin to reveal themselves, and management can accept it as a process worthy of their trust--even if they don't trust those weirdos developing the software..

Usability research material

This might be really useful to somebody desigin UI's: BetterDesktop.org releases video of users using several different applications to aid in software usability research.

Creative process

No doubt countless texts have been written to analyze the creative process among musicians. But, I'm a Rush fan, and a pragmatist--so something about this description of the album creation process by Neil Peart appeals to me.

Inspiration, passion, and muse are almost always snuffed out in formal software methods. They're probably the true tenuous thread that ties Agile to reality and makes it sing. I strive to build into development processes some freedom for true creativity. Regardless of what we need to do to get work done, those qualities are what programmers are in the business for. Without the freedom to practice them in the process, quality suffers and turnover is high.

Software development is like..

I've heard it proposed that software development projects are no more "repeatable" than is a movie product. And that, in fact, software projects are more like a movie production than the engineering efforts that CMM attempts to model.

This doesn't sit well with me, not because it's not a good point, but because it implies that this is the most accurate analogy for a software project. The irony is that the argument against "one size fits all" in CMM is the same argument that scuttles the movie production analogy. That is, many software projects are not like a movie production either.

I've come across another anology, this time on managing IT, by Chad Dickerson.

Good analogies, both. The danger here is that if one thinks about these analogies too deeply, one risks applying the wrong principles to the project.

In reality, software development is like.. software development. There are are two dimensions that perturb the principles of management of analogous efforts. First, the permutations of stakeholder interest, technology, market, talent, time, and money make every software project different than every other. Like people, software projects have genes--the permutations of which make every one unique.

Second, the patterns that are implicit in software projects combine many contradictory forces. Two examples are art and engineering. Practical necessities of software projects often require that we leave detailed design up to individual developers--making them craftsmen as much as engineers. In this mode some part of the individual is motivated by aesthetic imperative and results in emotional investment in their work. An engineering perspective does not typically respect these forces, and conflict ensues.

In the end, software projects are an expression of the combined styles of many individuals, that require the flexibility and ability to adapt to change that only thinking humans are capable of.

Update:

Since this post originally aired, I saw that Eric Evans posted something on his web site along the same line of thought. See Software is (not) like that. What he said.

Real Programmers..

It's been probably 30 years since the original, "Real Programmer's Don't Write Specs." The argument is alive and well. I'd bet that Linus qualifies under the definition of a hacker. Not that that's necessarily a bad thing. Joel on Software has an old, but still current counter-point.

Gregor Hohpe goes to Google

I just noticed that Gregor Hohpe has been hired at Google. He's got a pretty cool book on Enterprise Integration Patterns. He has put together a nice website/blog that augments the book nicely.

Just another happy XM customer..

I was first exposed to XM when I rented a car in Las Vegas and had a 6 hour drive home. It was fantastic because I had 150 channels to choose from, no commericals (almost) and could listen to whatever station I wanted no matter where I was between Nevada and California. For my birthday my wife got a pretty good deal on a used Delphi MyFi receiver.

I happen to like the XM service because they carry all the MLB games. It's difficult being a Dodger fan who's not in the LA area because the Dodgers typically broadcast their games in their local market stations and you rarely get access to them on syndicated TV networks like Fox Sports.

XM has multiple channels for most music you can imagine, pop, rap, country, jazz, etc. Oddly, they don't have much (any?) classical. They also have news and various type of talk radio. My favorite is the (uncensored) comedy channel.

You can go to XM's web site and sign up for free trial access to most of the same programming you can get on the radio.

This is a sattelite signal, so you're not just going to get reception any place you want. The funny thing about these high frequency signals is that reception can be inconsistent from location to location. In my office at work I can get a signal no problem, but in my house I have to set up the antenna just right to receive.

Also, keep in mind that the signal is highly compressed--so the sound is not CD quality. They seem to vary the quality such that news/talk radio is lower quality than music. In general, the music quality isn't any worse than your local FM station. But it's not some earth shattering digital quality you might expect from a digital service.

Personally, I hate the crap they play on commerical FM radio--there never seems to be a channel that has what I want to hear--and it seems like they play commercials 50% of the time. The "morning show" crap they have every morning is the last thing I want to hear during my 40min drive to work. So XM is a great addition to CDs.