Vendors are Risky Too

April 13th, 2009 4 comments

“We’re not a software company” is a common refrain these days; ever since Nicholas Carr’s “IT Doesn’t Matter,” it seems like more and more companies are bending over backwards to prove they don’t do IT. In the process, some consultancies have made a ton of money, often by “replacing” a given company’s IT department with the newly hired agency replete with people from….the company’s former IT staff. More than a few of my friends went to work one day as an employee of company X only to enter the office the next day via a contractor badge. As companies aped one another, we heard more and more about “core competencies” and how smart companies stuck to what they did best.

Implicit in this arrangement is a transfer of risk – and many (on both the business and IT side of the shop) equate vendors with risk free, or at least, if things go south we have a throat to throttle. While it can be empowering to scream at a vendor rep, that doesn’t mean you’ll get your problem solved – or that they’ll even be inclined to try. Vendor priorities mar or may not line up with yours and more often than not, that service contract entitles you to the C squad, not the A players they showed you during the courtship.

Make no bones about it, when you saddle up with a vendor, it’s a commitment, one you best enter into with your eyes open. Just like with your spouse, year two is rarely the same as the first date and having a phone number to call doesn’t mean you’ll get an answer you’ll like – or even an answer at all. Sure, you can open a problem ticket, but when will it be resolved? Don’t hold your breath, unless your CIO calls their CIO at least. Oh, and never assume the vendor’s developers write higher quality code than you do – some of the worst smelling balls of mud were slung by people working for “software companies.”

While we’re on the topic of software companies, don’t automatically think that the vendor is anymore of a “software company” than you are. It may *seem* like they’re in the same camp as Microsoft or Oracle, but take a look at their income statements – does “professionals services” make up a large percentage of the bottom line? Odds are it does, the software is the modern day equivalent of razors; they’ll darn near give it away (OK, if you call 7 figures “give”) so they can line up a nice fat services contract (mmm, smell the subscription fee!) In some cases, your odds of successfully implementing the project rapidly approach zero without a significant investment in contractors at $250 an hour and up. Nice work if you can get it.

Speaking of contractors, before you pull the trigger on that shiny box of vendor joy, take a look around the job boards to see if anyone is looking for developers with that skill set. Better yet, have your HR people look over recent job applicants to see how many boast time with your new love. Staffing models aren’t always at the forefront, but if you can’t hire people to twiddle the vendor bits, take a look around your cube farm and be sure you’ve got something people will want to train up on. Don’t be surprised when your techies aren’t thrilled by the notion of babysitting a piece of packaged software.

Once you’ve committed to a vendor, you live life on their schedule. Occasionally you might be able to nudge things but chances are you’ll be treated like the rest of the huddled masses. In some cases this might be just fine, but in others it can have a significant impact on your business. Found a critical bug? Odds are that won’t be fixed until the next release…sometime next year. You’re also stuck with their priorities and again, while you might have some influence here, more often then not, your pet feature isn’t so important to the decision makers at Vendor Co.

When you bring in a vendor, expect a platform play – and not all platforms are created equally. The excitement in Java land these days isn’t over Java the language, it’s Java the platform that gets the much deserved press for housing the likes of Clojure, JRuby, Scala, Groovy (hint, your developers would love to play with any of the preceding) and a host of others. While the Java platform (and it’s peer from Microsoft) offer a slew of choices, the vendor’s platform is probably designed like the Hotel California; once a company has invested time, effort and money, they will usually continue to throw good money after bad.

I’m not saying you should never purchase a vendor product – far from it. You shouldn’t write your own database server, you own app server, your own OR mapper or your own build framework (OK, maybe as a replacement to Maven, sure I can see that.) But when it comes to core competencies, the things that make your company special, that’s not something you should be too keen on farming out. As my friend Neal Ford is fond of saying, smart companies understand that IT is strategic.

When it is time to purchase some software, perform a true evaluation – and one that’s up to date. Just because the Foobaz team gave the product the thumbs up three years ago doesn’t mean they’d say the same thing today. Heck, that team might not have even considered the same criteria you are. Too often, we either run through a script that is oddly similar to the vendor’s demo or we try out a couple of hello world size examples; you’ve got to spend some quality time with a product to figure out when Dietzler’s law kicks in. Regardless of what you’re evaluating there are certain things you should pay extra special attention to:

  • The testing story. If a tool doesn’t have a good *automated* testing story, fail, or as we say in the project room, frog in a bag (FIAB for short).
  • Version control. Repeat after me: copying the files to the LAN isn’t version control. Life without source code management just isn’t worth living, if the tool doesn’t fit within something like Subversion or Git, your evaluation is over.
  • Can you diff the artifacts? I’m a fan of pictures, but show me the tool that can diff that fancy BPEL visualization. Oh and good luck with those massive XML files.

I’m sure you have other criteria too (Neal has a good list in part three of his SOA series) but these three are absolute deal breakers for me. Again, I’m not saying you should build everything, but when you do choose to purchase, be sure you know what you’re getting into. Can you live with the constraints? Are you comfortable with the tradeoffs? If so, I wish you all the best. But don’t blithely assume vendors aren’t risky.

Categories: Development, Rants, Software Tags:

Keynote 09

March 29th, 2009 4 comments

I’ve been a big believer in Keynote since shortly after it came out – at first I didn’t see what all the fuss was about, but after using it for a few months, I had to create a presentation at work and I was reminded of how painful PowerPoint is. There was no going back, I was sold on Keynote. Like so many things in the Apple ecosystem, it isn’t any *one* feature that makes the difference, it’s a collection of little things, some of which you didn’t even know mattered until shown another way. Unlike it’s cousin from Microsoft, Keynote is designed to help you create slides that won’t make users yak and it’s particularly well suited for those that believe in the Lessig method (see his Free Culture talk for an example.) At this point, I can’t imagine using anything else for a real world talk.

Every year, we’re treated to a new version of Keynote (and the rest of its iWork brethren) which means we get a collection of new features: transitions, themes, better charts and now new ways of sharing our work with others. Keynote 09 is no exception, this year we’ve got magic move and you can even use your iPhone as a remote. Before this year’s conference series kicked off, I went ahead and upgraded and while I’m quite pleased I did run into one issue.

As I crafted one of my early decks, I noticed that one of my favorite transitions from Keynote 08 was gone – for example, I couldn’t find confetti.
Keynote 09 stock transitions.
It may seem strange for an unabashed promoter of Presentation Zen and slide:ology to be married to a transition, but I go out of my way to use them judiciously. A slew of Google searches later, I had my answer – some transitions were considered obsolete in Keynote 09. Enabling them is quite simple, simply go to the Keynote preferences and select “Include obsolete animations in choices.” Perhaps I should just accept the wisdom of Apple and, ah, transition to the new animations but I’ve just got to have my confetti!
Keynote 09 preferences - enable obsolete.

The other big change I noticed was the vastly improved printing dialog. While nothing has fundamentally changed in the dialog, with 09, you get a handy preview of just what you’re going to print (or save as PDF – one of the unsung features of OS X.)
Keynote 09 print dialog - vastly improved, now with a handy preview!
You can also change the page setup from within the print dialog, something that is very handy when you’re creating PDFs for handouts.
Keynote 09 print dialog - vastly improved, now with a handy preview!
Oh and for those of you that like the black or gradient background, if you don’t want to kill an ink cartridge, select “Don’t print slide backgrounds or object fills.”
Keynote 09 print dialog - vastly improved, now with a handy preview!
Keynote is an invaluable part of any presenter’s toolbox – if you think its just an Apple version of PowerPoint you’re wrong. If you haven’t tried it out, you owe it to yourself to use it for your next talk, it really does make a difference.

Categories: Off Topic, Rants, Talks Tags:

Speaking at TSS JS

February 18th, 2009 5 comments

March is a busy month on the conference circuit – in addition to speaking at QCon London, I’ll be at’s Java Symposium talking about DSLs in JavaScript (yes Virginia, there’s a real programming language in there.) They’ve lined up some great speakers – should be an amazing show!

I'm speaking at TSS JS 2009!

Categories: Talks Tags:

Speaking at QCon London

February 7th, 2009 1 comment

Just a quick note to say I’ll be speaking at QCon London in March – I’ll be giving a talk on DSLs in JavaScript. Looking at the schedule, it should be a heck of a show and I’m really looking forward to spending some quality time in London! Oh, I have a discount code if you’re interested in attending…

I'm speaking at QCon London 2009!

Categories: Development, Talks Tags:

JavaWorld Podcast – Ajax developer’s toolkit

January 26th, 2009 2 comments

A recent chat with my good friend Andy Glover (of “Jolt award finalist” easyb fame) has found it’s way up on JavaWorld’s podcast page. Andy has a good overview of our conversation over on the Disco Blog. I had a blast covering a topic near and dear to my heart – have a listen!

Categories: Ajax, Talks Tags:

It Isn’t the Uniforms

January 18th, 2009 1 comment

If you’re a football fan (American style) this is a big weekend – the AFC and NFC championship pit (pun intended) a couple of six seeds vs. a two and a four respectively. Much will be made in the off-season of just how the Cardinals made a Giants like run or how the Ravens went so far with a rookie quarterback and you can bet your morning mocha that a couple of hundred coaches will be dissecting everything the champions did to win today’s games. Yes, imitation is the sincerest form of flattery and many will attempt to copy the winning formula.

It isn’t just sports franchises that imitate each other and raid the winner’s coaching staff, no, companies do the same thing. From performing the same morale sapping rifs to utilizing the same bland beige decor, corporate entities love to ape one another. Even within an organization, the “successful*” (however that is defined) VPs will find their ways quickly copied.

While we should certainly ask ourselves what’s working and what’s not, we need to make sure we understand what actually is working. Take Arizona’s success for instance. It may make sense to look at their offensive approach (as well as their coaching staff) to see what gems one might find. However, it takes a great deal of effort to find the golden nugget and most won’t put in the time. No, many will take a shortcut and insist that the Cardinal’s owe their Cinderella year to the color of their uniforms or the fact that Kurt Warner wears a glove on is throwing hand. Not only is the superficial easier to find, it is far easier to implement. Uniforms can be changed in a few days, establishing a winning tradition can take years.

In the technology space, it’s tempting to just copy a specific technology stack and it’s certainly easier to just buy the same vendor supplied vaporware than to hire better developers. But chances are you won’t be capturing the true essence of their success, you’ll just change the color of your uniforms.

So before you run off and decide that all new software in your organization should be written in that awesome new CASE tool that’s Bob’s team uses, be sure that’s the real secret sauce and not an ancillary fact. Odds are if you dig a little deeper you might find something else, something actually worth replicating.

* Unlike the sports world where a win is a win, success in the corporate world can be defined and then redefined especially when someone’s bonus is involved. Worse, sometimes one area’s success comes at the cost of the overall organization.

Categories: Development, Off Topic, Rants, Software Tags:

Speaking at CodeMash

December 29th, 2008 2 comments

I’m a bit late in announcing this, but along with fellow Fluff Talkers Ken Sipe, Andy Glover and Venkat Subramaniam, I’ll be speaking at CodeMash 2009 this January! I’ll be talking about Dynamic Languages and the JVM as well as Test Infecting the Legacy Organization. The show is sold out and I’ve got to admit the idea of hanging out at a water park in the middle of winter sounds darn appealing! Hope to see you there!

I'm speaking at CodeMash 2009!

Categories: Development, Software, Talks Tags:

Rewrites Are Like Moving

December 14th, 2008 1 comment

Moving is one of those things that (hopefully) we don’t have to do that often; it takes a lot of time and energy plus it is a real pain in the behind. But, every so often we have to pick up stakes and when we do, we’re usually amazed at just how much stuff we’ve accumulated. This is particularly obvious when you’re in college – I distinctly remember packing for the summer wondering how the heck I’d get it all home; I’d only needed one trip up in the fall, why would I need so many in the spring? And then it would occur to me. I’d made several trips during the year, where I’d innocently bring one or two items, maybe even a bag of stuff. Over time, the bits built up.

Software works the same way. Over time, a feature is added here, refined there and before you know you’ve got a mature product. And a messy codebase. Eventually this will lead to a rewrite often accompanied by a technology change of some sort or another (this time we’ll get it right!) Rewrites can be pretty good projects but they’re not without their perils. For one, customers usually won’t spend much time defining requirements. I’ve often heard “it needs to work just like the old system…only better” with better being some vague hand-waving around a pet peeve or two.

In addition to vague requirements, rewrites tend to suffer from estimation fatigue. Customers are convinced that they need to have all of the old system’s functionality (plus all the new doodads they thought up over the last 20 plus years) and they need to have it *right now*. Like my college aged self in the spring, many customers loose site of the gradual build up in functionality of the existing systems and many will insist that the new one won’t be useful until it fully replicates the old. That last statement doesn’t hold water but good luck convincing someone that feels otherwise; the old system didn’t have all its features on day one either but that’s not the anchor point for the people asking for the new system.

Rewrites are an excellent opportunity to do some process reengineering and, if done right, usually results in a vastly improved workflow. Of course this requires us to look past the angry monkeys in our systems and think of how things could be rather than how they currently are. This step is often skipped though, and we simply end up further codifying the legacy approach. But at least it’s in a new technology stack.

Whenever I’ve moved, I’ve used it as an excuse to prune some of the stuff I’ve accumulated over the years (hint – look for boxes that you didn’t unpack the last time you relocated.) When you encounter a rewrite, see if you can’t do the same, try to eliminate some features, reports or screens. Most customers will scream bloody murder when you suggest clipping things, but half a product beats half-assed any day of the week. Writing code is like writing prose, the important bits are the ones you cut – applying this approach leaves you with a smaller codebase that’s easier to maintain. Besides, the code we don’t write is bug free.

So, next time you’re staring a rewrite in the face, see if you can’t cut some of the detritus; odds are you don’t really need all 283 “views.” But instead of using words like eliminate, try defer – most customers will see that as less scary. Be sure to remind them that you can always add that in later when you have a better sense of what you actually need. Odds are those “must haves” will slip quietly to the bottom of the backlog.

Categories: Development, Software Tags:

The Importance of Retrospectives

November 14th, 2008 No comments

Today we learned something important, the NTSB announced the results of their investigation of the the 35W bridge collapse. Turns out it was a design flaw – some gusset plates weren’t quite up to snuff. As a result of this tragedy, bridges of similar design will undergo much needed scrutiny and we won’t see these types of designs in the future. Heck, by now engineering textbooks have probably already been updated.

Contrast this with the average failing software project. Maybe this is a bit of stretch (much like the bridge construction metaphor) especially considering that few software failures result in the loss of human life. But when was the last time anyone published a report about what went wrong with a multimillion dollar software collapse? No, we bury our mistakes (near Jimmy Hoffa) and pretend that the next time, when we do it JUST like we did it this time, it will work. It’d be too difficult to admit we did something wrong, even in the “safe” confines of our own organizations protected with lengthy NDAs.

Retrospectives are a vital part of creating better software but to be effective it requires a level of maturity that few organizations posses. Taking an honest look back at what happened, what went well and what went wrong leads to better results but only if you can discuss the project/increment/whatever openly and more importantly change how you do things. Life is full of constant adjustments, why should software projects be any different?

Categories: Agile, Development, Software Tags:

Duct Tape and Bailing Twine

September 18th, 2008 No comments

I spent my formative years on a small hobby farm. In addition to witnessing first hand the whole circle of life thing, I learned just how versatile duct tape and bailing twine can be. Of course I also learned that those temporary solutions rarely stood the test of time – or a stiff wind. Still, in a pinch, the quick and dirty solution isn’t always wrong provided you understand the consequences.

In software, we’re often pressed to slap something together, to hit a date, to use duct tape and bailing twine. Sometimes that is absolutely the right thing to do – the merger closes on the 1st, booking revenue requires the product to be released in the current fiscal year or marketing needs a demo for a key conference. Like our temporary solutions on the farm though, these improvised systems aren’t meant for the long term (or more than three users.)

While no one seems surprised when a quickly constructed lean-to falls over after a few days, people are stunned when jerry-built software isn’t up to the task. Some of that is the nature of software – people can *see* the temporary nature of our quick fix in the real world, but it takes a developer to really appreciate the craptacular nature of some code.

The problem isn’t (necessarily) with the quick fix, its expecting too much of that rushed work. Well, that and deciding that dates are far more important than, you know, quality. Many seem to forget the cost of releasing a bad product. Best case results in a pulled release or paradoxically another quick fix; worst case is a pulled product or lost customers.

So yes, sometimes we should cut some corners but we need to do so with our eyes wide open. And we need to make sure our customers understand the consequences of doing so.

Categories: Development, Software Tags: