POCOs, POROs, POGOs, Oh my!

In reading this ServerSide.NET article about Gigaspaces extending itself to "plain C# objects", I realized that Plain Old C-sharp Objects (POCOs) or Plain Old C-Sharp Objects (POCSOs) hadn't passed into .NET vernacular yet.

Far be it from me to stop progress. So unless one of you can show me some prior art (Google search didn't turn up anything obvious), I hearby coin POCOs and POCSOs, for .Netians everywhere.

And while I'm at it, I think I'll swing for the fences and coin Plain Old Ruby Objects (POROs). Take that, Parsons, Mackenzie and Fowler!

I'm tempted to go for a hat-trick and choose a third language. How about POGOs for Groovy?

UPDATE: I've had to cancel the patent applications. Looks like POGOs and POROs have prior art, and POCOs are just PONOs revisited. Clearly I'm just not hep to the language you kids are talkin'.

The Apple 'Switch' and Internet Statistics

With so many developers and techies happily blogging about their Apple experience, I was curious if the 'switch' was visible in public browser statistics. The answer seems to be 'yes' and 'no'.

Yes, there is a noticeable upward trend in the use of MacOS as visible in these statistics:

• w3schools
• hitslink

No, the shift does not seem to be, at this point, significant enough to really describe a trend. It's much like developer/techie adoption of Firefox. It's an interesting trend, but it hasn't made up nearly enough ground that we could make any prediction about the mass market.

If you're Microsoft, maybe this stuff keeps you up at night, and maybe it should, but for the rest of us, status quo prevails.

How to Recruit Developers Redux: Idealism, Personal Ads and Reddit

First of all: Hi, Reddit. I was surprised when I logged into Google Analytics this evening and saw my graphs spiked heavily today. There's been a fair amount of traffic today, so I wanted to continue the dialogue on some of the points that were raised.

Idealism
Byrne's Eye View argues that my essay gets idealistic as it goes on, that, in essence, most jobs suck, and that there's really nothing to tell.

Fair enough -- there's some merit to that. If everything you could say about your project, your company and your potential employee is, in fact, likely to scare away the candidate, maybe you're better off keeping it generic:

We're a small professional services firm in a tiny, windowless office in a character-free section of the Toronto downtown. Our sales staff has done their usual botched job of overselling the client on features and timelines that we can't possibly deliver, so we're desperately seeking staff with which to pad the project team so that we can show the client how hard we're working. Your coworkers are beaten-down developers that don't have the initiative to look for other employment and contractors who only show up because we're paying their high hourly wage to put up with our bull$h|+. Please apply.

If you feel this way about your company, then I'm going to have to suggest that you work on refining your resume instead of your job posting. That said, I hope that many of you do, in fact, feel there are redeeming qualities to the work, the company and your attitude to employees that just aren't getting out there.

I'm not ducking the point. It's true: the 'sales' job here will be really easy for some companies, and pretty hard for others. But if you focus on what appeals to you, or to the software developers who you employ, and try and make sure that what you post hits those points hard and gives some context, I think you'll find that you're already better off than most job postings that have been generified by recruiters and well-meaning but hapless HR wonks.

Personal Ads
As I was on my commute this morning, after posting, I was thinking how this advice sounds a lot like the kind of advice you might give someone who's preparing a personal ad. That personal ads and job postings aren't entirely dissimilar. Apparently I'm not the only one thinking that, as discipline and punish proved.

That said, I think some personal ad writers and readers thrive on being treated as a commodity, some don't. Personal ads are also, space-limited in ways that job postings aren't. But there are certainly points in common. You'll find that people describe their fondness for candlelit dinners and walks on the beach rather than their skill at romance and cooking. Those are immersive, context-rich ways to get the same content across. I don't think a job posting has to be so oblique, but you do want the posting to resonate with the reader, and dropping the bullet-point skill list in favor of evoking an atmosphere may not be the wrong choice.

In Other News ...
I'm sure there were other comments that I've missed. Feel free to drop me a line, post a comment, or keep the dialogue running.

I've considered, a few times, what it might be like to run a recruiting firm run by developers for development jobs. Could we do a better job of recruiting than recruiters do? I'd be curious to find out, but not curious enough to try.

Access to Capital

According to infectious greed, Canadian startups have pretty good access to capital. Although it looks like 2006 was a better year than 2005.

This is interesting, but I agree that it doesn't necessarily correlate well to dominant, successful startups and a the culture needed to create and sustain these.

Still -- with all that money flying around, does anyone want to offer me some?

SOA as SQL

It's an interesting idea: using a SQL-like query language for your service API.

The 'purpose' behind many service APIs is to store and retrieve data on a particular subject remotely. In a lot of ways, SQL seems like a good metaphor for doing so. It allows you to cherry-pick the data you're interested in, join it with other data, etc.

It'll be interesting to see if this is an idea that gains any traction.

How to Recruit Developers: Attractive Job Postings

Most job postings for software development jobs are terrible. Completely unredeemable. In the last ten years, I can count the number of interesting job postings I've seen in Toronto on my hands (and, yes, I have the normal number of fingers).

Your job posting is your first point of contact with potential candidates: your first chance to market yourself, to make your case. This posting can increase the odds that really great software developers will apply to your company, or it can ruin them. If you fail at this (and I can tell you, most companies do), you've seriously damaged your chances at attracting a good-to-great developer.

Who's Watching?
You can group the pool of potential candidates into three broad areas:

• Desperate Job-Hunters
• Job-Hunters
• The Curious

Desperate job-hunters are developers who really, really need a job. They haven't worked in the industry, or they're already between jobs, of they have a job they really hate, writing RPG or MUMPS. You can't drive these people away with a stick. If they're completely unqualified, but think there's any chance in hell of even getting in the front door for an interview, they'll apply.

Job-hunters are looking for a job, but they aren't desperate. These are developers that probably already have a job they can live with, but they're out looking for a different one. They'll read your posting, and if it looks interesting, they'll apply.

The curious are developers who aren't looking for a job, or who tell themselves that they aren't. They've got a job that they're content with, but they're willing to consider an opportunity. They're keeping an eye on the market, or looking for exciting opportunities, or just have a friend who fits one of these three categories. These people are the hardest to attract, and are likely to respond to postings only if they're seriously intriguing.

Desperate job-hunters will track you down. You'll need to work a little to reach the job-hunters, and you'd need to work hard to reach the curious. Interestingly, I suspect that the groups that are harder to reach also contain a higher percentage of good and great developers, because these people generally find good jobs and are able to keep them.

So: here's what you have to gain by writing a great job posting. You'll increase the odds of reaching a wider audience, and more great developers. You can hook them, catch their interest, and maybe, just maybe, get them to apply. Once they apply, your chances of hiring the best candidates go way, way up.

How to Repel Software Developers
Having seen a lot of incredibly bad postings, it's very easy to point out some of the flaws inherent in many job postings:

• Don't Describe The Job
• Don't Describe Yourself
  
• Describe the Candidate as a Commodity
  

If you accept a position, you're going to spend at least a third of your day (almost half the waking hours) at your new job. Most people are going to want to know how they're going to spend that time. The people who don't are probably just looking for a job, any job. Many positions don't describe the job at all. If you want to keep some details private, that's understandable, but share as much as you can. Help your potential new employee be excited about the opportunity in front of him or her.

After the job, the next thing a candidate will want to know is something about the company. You can either try and tell them something about the company in the posting, or direct them to public information about yourself, like a website. Either way, it helps to give context, to give some idea of what you do, what the job's about, and with whom you'll be sharing your work-life.

Finally, it's great if you can tell the candidate what you're looking for without describing them as a commodity. A 'resource', or someone with five bullet-point skill classifications. What kind of person are you looking for? Do they need a passion for development? Does it help to have a background in medicine? Outside interests? These help the candidate to see themselves in the position, rather than see the job as generic.

I've noticed over the years that these flaws are extremely common in recruiter postings. I'm not sure if this is a desire to keep the candidate and the company from finding each other without the recruiter's help, but it's a great way to make a posting seem extremely generic. If you must work with a middleman, see if you can get them to avoid the above flaws. Some sites seem to encourage or accept these more than others. Workpolis.com shows a lot more of these generic postings than monster.ca.

Here are some examples of job postings that exhibit these characteristics: "J2EE Developer", "Java Developer". You don't want your postings to look like these.

What's the Alternative?
So what should you do instead? Describe the job. Describe the company. Explain what you're looking for in a candidate. Make it sound fun, exciting. If you're using neat technology, tell us about it. If you're trying to save the world, include that. Maybe include your answers to the Joel Test. This is your chance, so make it good.

What do good postings look like? This is better. It's not brilliant, but it's better. It talks about the company, the project, the approach. It uses a few selling points about the technology and team.

And what about Tim Fennell, who wants to know what they're doing wrong at the Broad Institute? I don't think the posting's bad. It's a little dense, and it doesn't describe the Broad Institute in detail. It could be presented in a more polished, more accessible manner but the basics are all there.

There are a lot of ways to attract good software developers, but if your posting doesn't get those points across, they may never get far enough to notice.

Lightroom 1.0

Now that Adobe Lightroom is out of Beta, I wanted to see how the final version has improved over the betas I'd tried. I enjoy Lightroom, but I find it to be a little slow and a lot flaky. Crashes were common, as were freezes and lengthy vacations where it was unresponsive.

Having played with the final version for about an hour now, I can say two things:

• I like some of the new features. Stacking, flagging, colors: these are useful, and some of these were things that made me want to use Bridge instead of Lightroom.
• It doesn't seem to be a lot more stable. In the past half-hour, it's gone down on me three times. While searching for information, I see that Adobe already has a very lengthy page of potential fixes. This is not a good sign when we're talking about a new product.

Have any of you tried Lightroom 1.0? Is it working better for you than for me?

Couples Therapy for Business and Agile Software Development

Agile software development practices and businesses have been trying to get along for a few years now. In some environments, they're able to find common ground, work together to solve each other's problems, and otherwise form a healthy relationship. In others, they can't even seem to have a conversation without squabbling.

After considering their commonalities and their differences, I propose a form of Couple's Therapy to resolve the differences.

Different Perspectives
It's important to start by recognizing that both the agile developer and the business manager have different perspectives, but that neither party is wrong.

Business managers need to plan: to write budgets, make business plans, and even put out release schedules. These are natural parts of running a business, and they're valuable in their own right. A business that doesn't make budgets and plans isn't likely to have the necessary resources, to meet their client's or market's timelines and is a business that's likely to fail.

On the other hand, an agile developer knows that requirements are almost always unclear, always changing, and that, in fact, the users don't really know what they want. They know the cost of implementation is, at best, a guess, and that the best way to manage this is through some kind of process that balances the constants needed to accomplish goals with the dynamism and need for change that makes agile processes so successful. To manage through constant course-correction rather than trying to predict the future with up-front detailed planning.

These perspectives can seem at odds. An agile developer is wont to say things like, "We don't know when it'll be done" and "I can't tell you what features will make it into that release". These statements can be disturbing to a business manager who is unfamiliar with agile processes or with software development in general.

On the other hand, business managers might say things like, "I need a committed release schedule" or "If you don't tell me how long this will take, I can't make a budget or get resources for this project!" These statements can be disturbing to an agile developer who hasn't learned how to interact with business.

Common Ground
Although these viewpoints focus on different things, there's far more common ground than some people realize. Most business managers have seen or heard enough about software development to know that it's unpredictable, and that software projects are hard to deliver "on time, on budget". A good manager also knows that plans are meant to be changed, that priorities shift constantly, and that nothing can be set in stone.

On the other hand, Agile teams know that they need to have resources, and that resources tend to come from budgets. They have planning metaphors, even if those aren't always the metaphors to which businesses have been accustomed.

Both businesses and agile teams desire successful project completion. Both need to react to change on a regular basis. Both thrive on up-to-date information. Both desire to understand the pace of development, and to make sure that the right features are built in the software at a reasonable cost. These commonalities are more fundamental and more important than the differences.

Working Together
So, having realized that both parties have different, valid perspectives, how can they find ways to work together?

Agile teams can help business to plan, to budget by estimating desired features, working on release plans and otherwise helping the business to understand how long it will take to develop software. As long as both parties understand that plans are subject to change, this planning activity can be valuable.

Agile developers and coaches can also help businesses to understand the positive aspects of agile development: the support of change, the emphasis on delivering value early and frequently and on delivering value through software rather than other artifacts.

Businesses, on the other hand, can accept that up-front detailed requirements and planning for software development is rarely as effective as everyone might desire. That many projects fail, and the ones that do are the ones that refuse to deal with the realities inherent in software development. Business managers can encourage 'up to date' information instead of encouraging an up-front plan that never changes.

Both businesses and developers need to keep the other up-to-date regularly on the factors that affect planning: team velocity, changes in scope, timeline and priorities. Keeping the flow of information open, honest, and frequent is just as important in a business relationship as it is in a personal relationship.

The two teams can then work together on adjusting plans, estimates and schedules based on updated information. This kind of collaboration is possible and normal when agile software development and businesses form and sustain a lasting relationship.

F3: Swing DSL, not Declarative Layout

I had looked at F3 a few times blog entries a few times, and come away with the impression that this was basically a configuration language for declarative layout. It isn't.

Looking at this entry, and the attached code, it's pretty clear that F3 goes way, way beyond layout, into behavior. This makes it more of a Domain-Specific Language for the user interface layer of Swing applications than a declarative layout configuration.

It's interesting that it does that, but it raises more questions than it answers, to me. What appeals to me about declarative layout configurations is two-fold:

• Java code is a pretty verbose way to layout a UI. A declarative syntax can be brief, because it's purpose-designed. F3 seems to have this capability.
  
• Java code is somewhat painful to forward and reverse-engineer, tending to result in layout code you don't really want to maintain, or that changes in ways you hadn't intended. My concern with F3 is that by going into behavior and taking on additional syntax, you run the risk of creating a DSL that doesn't match well with visual layout tools, and has the same concerns with forward- and reverse-engineering.

Of course, since F3 isn't really paired with a UI builder at this point, the second bullet may be moot.

Language Bias for OpenXML and ODF

It's amusing to see, in Microsoft's Open Letter 'Interoperability, Choice and Open XML', the bias in the language used to describe Open XML and the Open Document Format (ODF).

On the one hand, ODF is: "closely tied to OpenOffice and related products, and reflects the functionality in those products."

On the other, Open XML "reflects the rich set of capabilities in Office 2007, offers a platform for exciting user productivity scenarios through user-defined schema, and was designed to be backwards compatible with billions of existing documents."

See any difference in the way these two are described?

Pots, Kettles, and Shades of Black
I'm not bashing Microsoft here; they have a position, and they're trying to state their side in a positive light, as many people would. I wouldn't be surprised in the least to find that IBM had described the two in a way that's equally slanted to their own opinions (although I believe that both sides of this argument have some merit).

I just hope that everyone reading these discussions is able to read through the marketing material, the positioning and the spin doctoring.

Merging Sessions with EclEmma

A subtle feature of EclEmma that I didn't notice yesterday is the ability to merge sessions.

While this certainly has application in areas where multiple test runs, suites or executions are responsible for some indication of 'total coverage', that aspect wasn't particularly exciting to me.

What I didn't realize is that this lets you merge in changes in coverage with a previous high-level coverage run. For instance. A test suite that I ran yesterday out of curiosity took 35 minutes to run through EclEmma.

Since that time, I improved the coverage of a few classes just to see the results. I can and did run a coverage test against those few individual tests just to verify that the coverage was as expected, but only this morning did I realize that I could merge those individual test runs back into the overall suite.

This allows me to get a decent 'update' of the overall coverage without running the whole suite again. Useful.

Eclipse Europa M4

Not satisfied with the Callisto simultaneous release, those Eclipse committers are at it again, this time with what is currently called the Europa simultaneous release. These guys want to be sure that, despite a wiki and a public plan, it's still absolutely impossible to come to terms with when the releases are out, and where you can get them.

A quick google search implies that Europa M4 was released in January, or is that Feb 7, or is that Feb 14th? Hard to say, because for the life of me, I can't figure out where (or even if) I'm supposed to be able to get myself a download.

Perhaps they mean 'release' in a "We'll talk about it, but you can't have it" sort of way. ("Want some? Psych!")

The Contents
Although the Wiki lists the projects in full, there are a few highlights:

• Buckminster: A component/dependency management system for Eclipse that should help to get people kick-started in a multi-project environment. Looks interesting, although I'll need more time and some experimentation to see how this plays out when compared to project-sets, a good multi-project source-control repository, etc. It has some promise.
• Corona: A tool-collaboration framework for Eclipse; looks like it includes, at least in demo form, some workgroup capabilities. Seems to share some intent with the Eclipse Communication Framework. There's some promise in here, but I'm not sure we're going to see it realized in the Europa timeframe.
  
• Dynamic Language Toolkit: Support for Dynamic languages, with an emphasis on Python, Ruby and Tcl.
• Web Tools Project v2.0: Apparently including WYSIWYG DocBook and JPA support.
• Mylar 2: I read many good things, but I didn't manage to find a match between my own way of working and Mylar 1, so perhaps I'll give this another look in Europa.
• Eclipse Modeling: I haven't used an Eclipse/UML tool that I'm happy with. Will be curious to see where this goes.
• Data Tools 1.5: I wasn't impressed with an earlier release of this; perhaps it's gotten better. I keep going back to Oracle SQL Developer for now as the (free) tool of choice to interact with Oracle databases.

Anything in there you're looking forward to, or have started using? Know where I can find and download Europa releases?

Eclipse Code Coverage with EclEmma

It's really great to see (via the Eclipse Awards) that someone has taken the time to integrate a free coverage tool with Eclipse: EclEmma.

I've used Emma before, but hadn't followed the recent development that sees it well-integrated with the IDE. Frankly, this was the one thing that really made the commercial offerings (e.g. Clover) attractive still, so now that Emma has taken this step, there's less reason to look elsewhere.

This, to me, feels like a great model for addressing test coverage -- right in the tool you use to write the code and the unit tests. Gives you a great capability to write tests, check coverage, and write a bit more.

Even more impressive, it seems as if EclEmma can also support loading coverage results from an external launch. So, for instance, if your nightly build ran a long project-wide coverage with Emma, it seems as if you'd be able to take the results of that coverage run, fire up EclEmma and see the results.

I'll be testing this out soon.

Access Keys in Firefox 2: Alt-Shift

I was having trouble using the access keys (e.g. keyboard hot keys) in Jira this afternoon. I don't use them regularly, so I didn't know what was likely to have changed since I last used them.

To go to the next item in the search, Jira was suggesting "ALT+N". I pressed "Alt" and "n", to no avail. Out of curiosity, after demonstrating to a colleague, I tried "Alt+Shift+n" to replicate the case of the 'N'. That worked.

A little research later, and I wasn't even convinced that the access key definition in the Html specification was intended to be case-sensitive or not. Fortunately, my colleague tried it in Firefox 1.5, and discovered that it worked for him, which made me suspicious.

A quick search on Atlassian's Jira instance later, and the answer was clear: Firefox 2.0 changed the access-key invocation sequence from Alt- to Alt-Shift-, and the tooltip on my Jira instance hasn't caught up yet.

So: if you're like me, and you don't use access keys very often in Firefox, this may be news to you as well.

Sensationalizing the News: Diet Soft Drinks

Somewhere in my Reader feeds, I discovered "Diet Soft Drinks Makes You Fatter". Following that to NBC, there was a slightly more balanced view, and following it further to the Health Science centre that issued the study, there was an even more balanced view on the subject.

There are any number of reasons for these results, and it's fairly clear that based on the information we have now, we have no idea what those reasons are. Imposing an unproven causal relationship on this correlation sensationalizes whatever value there was in the original data.

So, for instance, if people who are already gaining weight switch to diet soda, this is one relationship that would explain the correlation. Don't get me wrong; it's possible that there are things we don't know about the body, mind and its reaction to the chemicals we stuff into soda (or 'pop', if you're Canadian), but the study doesn't pretend to know the reason behind the correlation.

Spring-Loaded Observer vs. TypeCollectorFactory

I've just re-read Scott Priolo's Spring-Loaded Observer Pattern on TSS. I had a similar desire to work with something like the observer pattern for an event model on a recent project. Scott's pattern works reasonably well, but you do end up having a fair amount of Spring XML for each listener you want to add. The MethodInvokingFactoryBean is a reasonable approach, but nine lines of Spring XML to inject a single observer can be a fair amount of Spring code, if you have a lot of listeners. (To be honest, I also hadn't thought about using it, but even seeing it, I prefer the pattern I've employed).

So where Scott's example does this:

<bean id="registerTownResident1"
  class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
   <property name="targetObject"><ref local="townCrier"/></property>
   <property name="targetMethod">
     <value>addListener</value>
   </property>
   <property name="arguments">
     <list>
       <ref bean="townResident1"/>
     </list>
   </property>
</bean>

I've done this:

<bean name="eventService" 
  class="CoreEventService">
  <parameter name="eventListeners">
  <bean class="SpringTypeCollectorFactory">
     <parameter name="typeToCollect" 
       value="EventListener" />
   </bean>
 </parameter>
</bean>

The SpringTypeCollectorFactory simply grabs all the items of a particular type from the context and collects them up in a list which it returns. This allows me to simply declare event listeners that match the EventListener interface and voila, they're injected into the event service.

More importantly, it means that client projects which consume our core spring configuration can simply add their own event listeners to their own Spring files and these two are picked up and added into the core event service.

Since this seems like something other people might be able to find good uses for, I'm sharing it, both here (this blog entry), and here.

Ideal Development Job: Location

One of the things I left out of yesterday's post was Location. That was deliberate; I've got mixed feelings about this.

Working from Home
Working from home has a lot of benefits. You save the commute time to and from work. You can take a few minutes in the afternoon to put dinner on. With the time you save, you can do a little exercise, run some errands. If you need to run a mid-afternoon errand in return for doing a little work after normal hours, it's usually not a problem. However, you have to be disciplined. Distraction is a phone call, or power switch away. If you turn the TV or the Wii on at lunch, you have to be able to turn it off again.

If you always work remotely, and it doesn't matter where 'home' is, this can be even more powerful. You can move wherever you like without worrying about your job. You can live somewhere where the expenses are low, or in places where technical jobs are hard to find. If you want to look out in the morning on deer and blue jays instead of traffic and sirens, that's your choice to make. On the other hand, if you go this far, you better have a stable job that you love, because if you lose that one, you may have trouble finding another.

Working from home can be lonely; you lose a major point of human contact, and may find yourself feeling a little divorced from the world outside. It's also much harder to do co-ordinated teamwork over the phone, skype and IM than it is in person.

If you've got people or pets at home, working from home is a good way to stay in contact with them. On the other hand, if you have three children who haven't started going to school, and a stay-at-home spouse, this might make working at home very difficult.

Working from an Office
Working from an office is a great way to stay co-ordinated, as a team, and a company. The bandwidth of face-to-face communication is much higher than you realize until you try the alternatives.

It also helps maintain a work/life balance without discipline. It's easy to have life bleed into work and work into life, if you conduct them in the same basic spot. If you physically go to work and go home, it's easier to keep these somewhat separate.

If you are going to work in an office, it's great to have a lot of interesting, inexpensive, close food options. As I've moved from office to office, that's something that I've valued about some locations over others. It's also great if that office is convenient to get to -- either relatively close to your home, or at least, a rapid, painless commute, whether that's transit or traffic.

What's The Right Location
I've done both. I like aspects of both. One of our cats is distant and sleepy at night, but very friendly during the day. I loved the flexibility that came with this, but I did end up feeling very divorced from the world outside. You'd find yourself talking to someone, who'd say something like "I really hope the weather improves; it's been soooo cooold this week" and you'd think, "was it?" You'd realize that you hadn't actually left the house this week.

I also found that it was much harder to work as a coordinated team, and that's important to me. But when I see open-source jobs that don't have a required location at all, it's interesting to imagine that I could be living in a really incredible locale, move as I please, spend less on housing, and still have a job in technology that I love and that pays reasonably.

What's the right location for you?

The Ideal Development Job

Someone asked me recently what I felt was an ideal job in an ideal company in software development. I hadn't thought about it in quite those terms before, but I've been thinking about it a little since.

So what would I look for?

The Team
I'd want a capable team of skilled people, who are both willing and able to self-organize. I'd want them to have gelled already, or be very capable of doing so. It's nice if they have enough opinions in common that they don't argue about approach, but enough areas of difference that there's a healthy desire for discussion.

I'd prefer this to be a team that I like on a personal level as well; I have to spend near a half of my waking hours with these people, so I'd rather enjoy it. Besides, teams gel better when they get along, are willing to spend a little time outside the office with each other, and maybe have lunch on a semi-regular basis.

The Process
This is more a question of broad strokes than it is the details. If the process is relatively agile, focused producing software, good communication and a tight feedback loop, I'll probably be happy with it. The farther down the path it is towards big-up-front design, waterfall processes, the more likely it is that I'll be struggling to accept that problems this causes.

That said, regardless of the actual approach, as long as the process seems to fit the environment, if people are behaving in a functional manner, I can probably live with it. The important thing is to reach the desired goals, not the process, the politics, the constraints or any of the other areas where people often get trapped in dysfunctional behavior.

It's just been my experience that agile processes encourage functional behavior, and that many other processes tend to discourage it.

The Company
A company that's building a product, not offering professional services. I've done both, and I can live with both, but I prefer the long-term focus of a product company. Professional service companies have interesting variety, but are too subject to the immediate whims of their clients.

Similarly, the larger the audience for the product, the better. Again, this isolates you from the whims of a single client to some degree. It's not that I believe that customers should have no input on a product, just that they shouldn't have you over a barrel.

The company should also have good representation in management of people who understand software and how to build it, and are in close communication with the software team. This is important to me because, well, I build software, and company projects rarely succeed without some kind of informed executive representation.

This 'close' communication is, by my definition, honest communication. I've seen too many instances where the communication from a software team up to company management resembles the "telephone game", where no single datum can make it from the team to management without being transformed so radically that it can't be recognized.

The Product
The more people who can see it, the better. It's fun to share your work with the world. This means that consumer software is interesting, more so than business-software, and general business software is more interesting than really niche software.

That said, the subject matter helps. If the subject is exciting, that might make a reduced audience worthwhile. And if it "helps the world" in some way, rather than being parasitic, even better.

Technology
Finally, the technology counts for something. Don't get me wrong, technology isn't the reason why projects succeed or fail (for the most part). But most of us developers enjoy learning, staying current, expanding our skill-sets and our horizons, so a chance to take on some technology now and again is both fun, and likely to help attract and retain good developers.

Whether 'new technology' means Ajax, Java 1.5, Ruby, Steve Yegge's NBL -- well, that's less important.

And so?
Does your company sound like this? Tell me. :) Have your own ideas? share 'em.

Eclipse 3.3M5 for Teams

Eclipse 3.3M5 has a few nice features, but of particular note for Teams is the ability to define a per-project setting for what happens when you save files -- optimize imports, reformat code, and so forth. This'll be good for teams that have already standardized on the use of Eclipse.

Other features that are new and notable in the JDT:

• Rename Refactoring in Java Editor (inline, no dialog, but still affecting entire workspace)
  
• Completion for Static Import or Catch Clause
  

(Briefly distracted by Mac ad: "You are coming to a sad realization. Cancel or allow?")

Debugging Business Rules in JBoss Rules 3.1

If you've spent any time using a business rule engine, particularly one that uses an approach like Rete, you've probably heard people argue that they're difficult to understand.

This is basically true. Business rule engines do a lot of the work for you; they determine which rules are relevant to the facts that have been asserted and in what order they should be run. This is often a strength, but when it comes to comprehension and debugging, it can be a weakness. It can be hard to imagine what's going to happen, and perhaps worse, hard to understand what just happened when you run a particular scenario.

There are usually ways to resolve this: tools and techniques that are provided by the rule engine vendor that help you to look inside of the black box. So it's nice to see that JBoss Rules (aka Drools) is enhancing this side of their tooling. I know this could counter some objections I'd previously heard.

Microsoft Trips Over Own Feet: VSS and VS.NET on Vista

The left hand of Redmond doesn't seem to know what the right hand is doing. They're tripping over their own feet. Even with all the mis-steps with Windows Vista, how is it possible that recent versions of two of their primary development tools don't run on their own operating system?

A few months ago, there was a a lot of chatter about the fact that several versions of Visual Studio won't work on Vista, and that upgrading might force you to upgrade the version of the .NET framework underneath. Now it turns out you can't host Visual SourceSafe on Vista either?

Baffling.

Apple: Drop the DRM

I'm happy to show my support for Apple's/Job's commentary on DRM (although I won't be the only one).

Fundamentally, this is the reason why I've never bought a single song from iTunes, despite owning an iPod and playing much of my music on MP3-capable devices.

Within the last year, there have been at least ten instances where I would have seriously considered making such a purchase, but haven't. Some of those instances, I've decided to purchase a CD instead -- perhaps making as much or more for said record labels. In some of those instances, I've "gone without".

If the labels and artists really want to see the power of digital distribution, they'll need to drop the DRM.

Sidecar Styles for SpreadsheetML (and Noisy XML Formats)

Spreadsheets are accessible. Business users, in particular, really seem comfortable with spreadsheets. That's a good thing, particularly if you want to ask a business user for some data that can be represented well in tabular form.

For instance, we have a multi-tenant product that requires a fair amount of configuration, and that configuration is often best done by business users with only a moderate background in technology. Those users would find an XML file onerous, and a text-file error-prone, but are more than happy to configure the application using a spreadsheet.

However, these business users are using Excel. Excel is a binary format, which doesn't integrate exceptionally well with a development toolset. For instance, it's fairly difficult to compare two Excel spreadsheets and find the differences. Normal diff tools (commercial examples include BeyondCompare, Araxis Merge) balk at providing a diff on a binary file, and Excel doesn't come with its own capability for comparison (unlike, say, Word). You can invest in a tool like Synkronizer, or you can save the spreadsheet to some kind of non-binary format.

This is where SpreadsheetML comes in. Excel can save its workbooks in an XML format called SpreadsheetML. XML is much more amenable to comparison analysis and human-readability. Unfortunately, most office/document XML formats have a very low signal-to-noise ratio: XML is verbose to begin with, and style and layout information can outweigh actual content by an order of magnitude.

In SpreadsheetML, this means that adding a few cells on a new row will result in a 20-row change, when you factor in the cell, row and data tags, the type, styleid and height attributes, and so forth.

Sidecar Formats
One of the things I've enjoyed about using Photoshop with RAW files (e.g. Canon's CR2 format) is that your current 'raw' conversion settings can be stored alongside the raw file in what's known as a sidecar file. As a result, the original raw file is untouched, and some additional information is stored where it's easily accessible, copyable, and so forth.

SpreadsheetML and Sidecar Styles
Going back to SpreadsheetML, wouldn't it be nice if the styling information were similarly stored in a sidecar file? This would buy a separation of content from form, the ability to provide more than one possible styling per data sheet, the ability to diff the data without having to get confused in all the formatting. This feels both more powerful and more useful.

me.dium: Deja Vu?

I read about me.dium on scoble's blog. While it seems well-presented, and the name is decidedly del.icio.us, I have to say that this feels like something that's been done.

Between the Alexas and the Stumbleupon and the countless other models, it seems like we've tried, repeatedly, to find ways to share the web-surfing experience, to make it communal, and the web-surfing audience of the world has repeatedly said, "No."

Am I wrong? Is me.dium different, or do some of you believe that we've been waiting for the right tool along to make this web experience something we can share?