An XP Room, Workspaces

Check out these photos from an XP developer room. I was in a conference call recently discussing Scrum, and the participants spent quite a lot of time figuring out what the workspace would look like: who was in it, the layout, how big it was, etc.

I’ve worked in all sorts of development settings from being crammed with 4 other people in a tiny office in the early days of Mesa/FundsXpress to having my own swanky office at BMC. Now that I’m in that swanky office, when the subject of working in a open-space comes up, I’m torn between the high-energy and exciting team-work that an open-space affords, and the quiet and augustness of an office.

In the end, I know I’d prefer to work in a open-space with co-workers for both productivity reasons and for fun reasons. It’s more productive because the effort it takes to communicate is extremely low since you’re face-to-face, and because the team knows what everyone else is doing, bringing in the benefits of transparency.
It’s more fun because you get to hang-out with people all day long, cracking jokes, sharing random thoughts, and sharing your coding struggles and triumphs with everyone.

Of course, depending on your mind set, all of those things can be the reasons why you don’t want to work in a open-space: it’s loud and chatty making it potentially hard to concentrate, you can’t hide out in your office and surf the web all day, and you have to be social with your co-workers all day long. There’s also a morale problem that can creep in along the lines of, “they don’t value us enough to pay for office space” and/or “the VP of Do Nothing has an office while we’re all crammed in this room.” There’s non-cynical reasons as well, e.g., the “programmers in offices are more productive than programmers in the open” research in Peopleware.

Anyhow, check out the pictures. There’s links to other pages that have photos of agile workspaces as well.

Using the Channel to Make Money with Open Source

I’m always interested in how people make a living around open source software.

Here’s a ISV/channel centric article from CRN
about the recent spate of open source support companies:

Unlike more general open-source consulting firms, MozSource and MozDev Group represent a growing number of cottage services springing up around specific, open-source projects such as Mozilla, Linux, Apache and MySQL.

But the expected proliferation of partners means that, sooner or later, open-source foundations will have to learn how to support their channels. Zach Urlocker, vice president of marketing for MySQL, said channels are springing up to serve different types of open-source organizations. These include partners that focus on traditional open-source foundations such as Apache and the Open Source Development Labs, which guards over Linux. And there will be solution providers focused on second-generation, for-profit, open-source companies like MySQL and JBoss.

As with many commercial vendors, open-source projects such as MySQL and JBoss will continue mixed direct and indirect model sales and services model. But they also recognize that they will have to partner with independent service firms–viewing these emerging cottage industries as a services ecosystem under construction. MySQL, for instance, launched its first channel program in April.

I’ve heard that JBoss is looking for such partners, so they’re no trying to start supporting the channel. And, indeed, they already have a partner program setup.

(BTW, what’s the deal with the term “the channel.” (1.) what’s the etymology of “channel” in this sense, and, (2.) how come there’s only one, why isn’t it “the channels“?)

They're Serious About Free magazines

I just got a call — at 8:12AM on this rainy morning — from Network Computing to renew my free subscription to their magazine. I hadn’t sent back the 50 million “renew your subscription now!” cards because I already get about 50 million free magazines that I instantly throw into the recycling bin. I guess they’re desperate enough for subscribers — free ones! — that they’ll pay someone to call up and walk you though that long form where you check off all your demographic boxes.

(And yes, I guess I somehow stupidly gave them my real phone number. I must have been having a stupid moment when I filled out the form.)

Don't Forget About the Application


Simon Johnston has an interesting comment on selling dev tools/environments
. Sometimes when he goes to customers sites, he first pitches all the fancy JSP/JSF front-end stuff Rational/IBM has, then he shows off the fancy schema stuff, and then…

So with all of this cool and exciting technology why do the [customer’s] faces looking back at me not look happy? Because, while all of these things may be necessary to the finished application, they are not the application. What I want, what I need, is the tool that helps me build the application and of course although there are certain known application patterns I will need to define my own or at least customize what is provided. I need the tool to provide guidance and structure so that I understand that I need pages, schema, classes and when and why I need them. Today’s developer tools (and not just those from IBM) focus very much on the individual task, a better page designer, a better schema designer and very little time on application design.

My understanding of software factories is that they’re an attempt at
solving that problem, needing a “tool to provide guidance and structure so that I understand that I need pages, schema, classes and when and why I need them.” I’ve only listened to Udell’s audio interview on the topic and quickly flipped through the book, so my knowledge of software factories is pure hype-fueled. It seems like the idea is that a vendor just provided a bunch of template/prototype code and code-builders that are domain specific and extendable. So, you might have the “HR software factory” that comes pre-loaded with a bunch of HR-centric stuff. The HR department shells out the bucks to get the factory, and then customizes it. Like I said though, my knowledge is just based on the marketing message.

I’m sure Rational/IBM has an equivalent type of thing, maybe MDA? I haven’t quite figured out how MDA is different than CASE stuff, but I haven’t read anything about it, so I’m probably just hung up on the “Model” part.

Falling Victim to Your Own Success

Here’s an interesting idea I haven’t encountered before:

An interesting risk comes near the end of a project, at the moment the
“consumer bit” flips. By this we mean that the users go from believing that
nothing will ever be delivered to believing that the team might actually
pull it off. The good news is that the external perception of the project has
shifted: whereas on Monday the users would have been happy if anything
were delivered on Tuesday, they become concerned that not everything
will be delivered. This is the bad news. Somewhere between the first and
second beta, you find yourself inundated with requests for features that
people want to be sure are included in the first release. Suddenly, these
become major issues. The project manager goes from worrying about
delivering minimal acceptable functionality to a situation in which every
last requirement is now “essential” to the first delivery. It is almost as
though, when this bit flips, all outstanding items get elevated to an “A”
priority status. The reality is that there is still the same number of things
to do, and the same amount of time in which to do them. While external
perceptions may have changed, prioritization is still very, very important.

If, at this crucial moment, the project manager loses his nerve and starts
to cave in to all requests, he actually puts the project in schedule danger
again! It is at this point that he or she must continue to be ruthless and
not succumb to new requests. Even trading off something new for
something taken out may increase risk at this point. Without vigilance,
one can snatch defeat from the jaws of success.


“From Waterfall to Iterative Development” [PDF]

Symantec-Veritas: Systems Management Bachelors, Easier Integration

It’s hard to Monday morning quarterback bigco software mergers. There’s always more going on than rational biz-thinking where two companies are trying to find the perfect fit. There are, after all, humans and big-cash involved. Those two are a combination that can effortlessly lead to making the reason for the merger to do the merger rather than anything else. I mean, look at AOL/Time Warner.

That aside, here’s some backseat driving from systemsmanagementpipeline.com:

Other observers, however, were left scratching their heads over the Symantec-Veritas deal. Richard Ptak, principal of consulting firm Ptak, Noel & Associates, said he wondered why Symantec chose to merge with Veritas rather than CA–or, better yet, BMC Software–to gain a broader-based infrastructure management solution.

“This would have given Symantec a solid position as a major player in systems management,” Ptak said. “Symantec quite clearly left the door open for further acquisitions in this space, but after they have completed this merger. Given the current trend in market consolidation, it is an open question about which firm will be available when Symantec is ready to move. But we would bet they will acquire again.”

The most insightful comment about the Symantec-Veritas merger I’ve come across so far — in several stories — is that there’s very little overlap between the two companies technologies. Symantec does security, Veritas does data. As such, they won’t go into the relationship figuring out what duplicate technology to axe. Usually, with software companies, getting rid of technology is the same as getting rid of the people who work on the technology: the folks who decide who’s heads will roll out the door typically don’t separate the two. And, of course, you can piss off key people by throwing out one of their “babies.” You know, it’s like when you move in with your sweetie, and one of you says to the other, “look, I know I you love that couch, but it’s gotta go. That couch is so college. It’s not going to be in our house.” RIP couch: I knew ye well.

More importantly, they won’t have to do too much consolidation of architectures, domains, or any of the other nasty things you have to do when you’re trying to integrate/merge together similar systems. Most of this type of integration and merging is slowed down by people hurdles — folks don’t want their architecture morphed into something else, they want the something else merged into their architectures — which are harder to jump over than the “simple” technological hurdles.

Anyhow, larger point being that when it comes to merging software companies, the underlying task of integrating and consolidating the software is always tricky. It’s difficult to integrate software together, and it’s almost impossible to integrate software people together. In the enterprise software world of today, you figure out those two problems, and you got yourself success.

Hypersonic DB (HSQL) in OpenOffice 2.0

Check out this article on OpenOffice 2.0 from The Inquirer:

One noteworthy addition to this upcoming 2.0 OO.o release is the
HSQL Embedded database engine a fast Java-based embedded database engine that once surprised everyone by beating IBM’s Cloudscape (now also open sourced) and even C++ databases. Also included is a user friendly database application dubbed “OpenOffice Base” which allows you to effortlessly create both databases, queries and reports using helpful “wizards”.

I encounter HSQL all the time, and use it my personal projects pretty much exclusively. The reason I like it is that it’s so simple to use: you can package up an HSQL DB by just including a few files, and then “start it up” simply by accessing it via JDBC. If you run it in embedded mode like this, it essentially can bootstrap itself.

Compare that to having your DB be a separate process (like MySQL or Oracle), meaning you have just one more set of files and processes to worry about. There’s tradeoffs between the two for sure. For example, the use case with OpenOffice is single-user (?), while with other DB’s it’s usually multi-user. On the other hand, it may be the case that in many supposedly multi-user scenarios, you could satisfy the requirements by giving each user their own embedded database.

All that angels on the head of a pin talk aside, the narrower point of the post is simply that learning that OpenOffice uses HSQL makes Hypersonic seem more “real” than it’s scrappyness would otherwise imply.

Kent Beck on Testing

I listened to Kent Beck’s
talk “Developer Testing”
earlier this week. I thought it’d be
boring — “write unit tests! yay!” — but as I should have guesses,
there were some good ideas about software development:

  • Testing software addresses developers being accountable to each
    other people in the organization. Accountability isn’t as bad as you
    might thing it is, because it means you spend less time arguing about
    things. If your software is “healthy,” all your tests will run. If all
    your tests run, your software isn’t healthy. End of story. No more
    debating.
  • If can’t easily write (unit) tests for your software, it means you
    have a poorly designed software. That is, being able to write tests
    for code isn’t a test-writing problem, it’s a design problem. With
    this idea, Beck all but says that J2EE is poorly designed: it’s hard
    to impossible to test, thus it’s poorly designed. “QED.”, as they
    say.
  • From the above, thinking about and planning for your software
    being testable starts right away when you’re designing it, not
    afterwards. Indeed, in pure XP, you’d write the tests first. Testing
    first always seems to confuse people, it starts to make perfect sense
    when you sit down to test some nasty code for the 40th time and think,
    “man, if this was just designed a little better, they test would be so
    easy to write.”

So, the main take away is: if you can’t easily test your software,
your software is probably poorly designed.