floky.com
Privacy

Archive

Archive for the ‘Rants’ Category

Good Ideas Aren’t Always New

April 21st, 2009 No comments

At QCon, Glenn Vanderburg, Michael Feathers and I (there may have been others, as I recall some ESB was involved…) were talking about Mike’s 10 Papers Every Programmer Should Read post (if you haven’t read it, please do so now, I’ll wait. No really, go on.) A lot of programmers aren’t particularly well read, a fact that Mike laments, and we kicked around some theories as to why that is – here’s mine.

Why don’t we look at our past? I believe it has to do with the natural (10 year or so) cycle of language dominance. People who’ve never programmed in language n-1 look at the syntax in a book from, say the early 90s and scoff; they complain that they don’t know that language thus they can’t read the book. I’ve heard more than a few developers dismiss Design Patterns because the code wasn’t in Java, of course Java is starting to wane – a couple of days ago I was researching a book and noticed it had a bunch of negative reviews because the example code was Java!

Many developers are essentially Blub programmers and they can’t imagine life in any other language. Further, they firmly believe that anything that existed before Blub is the modern day equivalent of the Pony Express, antiquated and useless. To some, all the good ideas are new, and we have nothing to learn by studying our past, I suspect many of these people have never seen the mother of all demos (though maybe we have something new to rival that now.) A typical Blub programmer assumes that any book that doesn’t use Blub isn’t worth his time and thus misses out on a wealth of learning. They almost willfully ignore the past which explains some of the reactions to Mike’s post.

I’ve been doing my best to read my way through 10 papers and this afternoon I came to Kent Beck and Ward Cunningham’s A Laboratory For Teaching
Object-Oriented Thinking
. Now, many people assume the whole agile software thing is just a few years old but here we see waaaaaaay back in 1989, a reference to YAGNI and a plug for teamwork:

We stress the importance of creating objects not to meet mythical future needs, but only under the demands of the moment. This ensures that a design contains only as much information as the designer has directly experienced, and avoids premature complexity. Working in teams helps here because a concerned designer can influence team members by suggesting scenarios aimed specifically at suspected weaknesses or omissions.

Great ideas then, a great ideas now. We’re a young industry, one that is further hamstrung by the belief that the language/technology/process du jour is all that plus a bag of chips. We’ve obviously made some huge strides, but in so many ways we’ve barely moved. But for the video quality, Engelbart’s demo could have just as easily been from 1988 or even 1998; sure, we’ve all got a mouse on our desk, but what about that 5 fingered keyboard? Not so much. Heck, every language is just trying to reinvent Lisp, and that’s more than 50 years old! Don’t be afraid of the past, those old guys knew a thing or two. We only hurt ourselves by ignoring the lessons they have to teach us.

Categories: Development, Rants, Software Tags:

Vendors are Risky Too

April 13th, 2009 No 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 No 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:

It Isn’t the Uniforms

January 18th, 2009 No comments

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:

Culture Kills

June 21st, 2008 No comments

Andy Hunt recently posted a great piece: Stage 0: Not Ready For Agile. He was all set to give a talk at a company until, well, someone discovered he was coming. Turns out the manager that contacted Andy hadn’t followed the non-existent process and instead of congratulating him or her on bringing in a well known speaker, they decided it’d be better if it could never happen again.

As stunned as I was by this, I’m not surprised. Talk is cheap – it’s easy to say you want to be (or are) agile but the proof is in the pudding. You can say you value collaboration but when there are three levels of indirection between developers and end users, that statement echos hollow.

Culture plays a huge role in how we build software; Andy lists several traits that indicate you might not quite be up to the challenge of agile. Some are fixed more readily then others but if your culture won’t support it, you’ve got your work cut out for you. Unfortunately, cultural issues don’t respond to technical solutions as Reg Braithwaite says so well with this quote:

“Cultural problems cannot be solved with technology. If you are an advocate for change, ask yourself what sort of cultural change is needed, not what sort of technical problems need to be solved.”

Changing culture is hard, but for many organizations, it’s the critical first step towards better software.

Categories: Agile, Development, Rants, Software Tags:

The Purpose of Process

June 21st, 2008 No comments

It shouldn’t be a big surprise that I prefer low ceremony agile processes to their heavyweight waterfall brethren. While I’m certainly not anti-process, I’ve spent way too much time in meetings defining how we were going to write software. Recently I wondered, do other industries spend so much time on mundane details like templates for issue logs? Perhaps they do, but I doubt the architects of the new 35W bridge spent a lot of time discussing the how they would document the plans for the new roadway.

Most companies I’ve worked for spend an awful lot of time and money on process. Much as no serious enterprise would ever consider deploying SAP or PeopleSoft without a hefty does customization, every organization wouldn’t dare to use an off the shelf process. No, it’s better if a group of people spend months coming up with the perfect approach and a set of presentations that would make Tufte weep. Despite a lot of pats on the back, I’ve yet to see this effort lead to any significant business value, yet it is a persistent part of the environments I’ve worked in.

It seems to me that most companies focus on process for one of three interrelated reasons. First off, there are a number of people in technology that, well, aren’t very technical. Some of these folks *used* to be, but many just bluffed their way into higher paying roles and well, they need things to work on. Of course not everyone needs to spend their free time brushing up on the finer points of the closures in Java, but last I checked templates don’t compile their way into working software.

Second, software projects have a nasty tendency to fail and to combat this fact, most organizations want greater control over the work. To accomplish this goal, they invent more and more process, more gates, more checkpoints. Of course it doesn’t really work that way, and the tighter they grip, the worse things get (hmm, sounds like a Star Wars quote to me.)

Project failure brings us to reason number three: plausible deniability. If (or is it when?) a project isn’t everything it can be, we can always point the finger at the process as either a point of blame (if only the process had a few more gates…) or as an example of success (as in: we’ve got a great process now…) Following the corporate standard also gives managers et al an easy out: yeah, the project failed, but we followed the all mighty process.

Don’t get me wrong, heroic software development isn’t good either. I’ve worked in manners best described as fire fighting and frankly that’s just too much stress for me (though some people I know absolutely thrive on that rush.) Like so many things, process lives on a continuum. At one end, we have absolutely nothing – hack and code, cowboy coding, whatever you want to call it. On the other end, we’ve got extremely heavyweight command and control approaches that attempt to plot out when every developer will use the bathroom.

Truth is often found between extremes and we should seek a balance. Do what’s right for your project though I’ll always favor the less is more camp. And before you spend the next few months creating the perfect process see if something off the shelf will work. Better yet, try some stuff and see what works for you – repeatedly ask yourself these two questions: what worked and what didn’t; do more of the first and less of the second and you might just find yourself on a successful project.

Categories: Agile, Development, Rants, Software Tags:

What a Great Idea

May 23rd, 2008 2 comments

Surfing my blog reader the other day, I couldn’t help but react to the news about Microsoft bringing ads to the Zune. Boy, that ought to *really* help sales. Reg Braithwaite has commented on this already but I’ve really got to wonder how long it’ll take companies to figure out that putting the customer first works. I think Reg hits on it – we aren’t the target market here, shareholders or marketing departments are. Clearly the music industry doesn’t get it but anyone want to wager on the likelihood of ads on an iPod? Only one US air carrier posted a profit in the first quarter and they consider themselves first and foremost a customer service organization. Huh. Wonder if there’s a connect there? Nah, couldn’t be.

Categories: Apple, Off Topic, Rants Tags:

Emergent Properties

February 17th, 2008 No comments

Like pretty much any office with more than 3 people, we struggle with the ephemeral concept of knowledge management. Now, this takes the guise of everything from cultural lore to more basic issues like where is the latest version of the FooBaz document but the moral of the story is simple: we’re still trying to find the right approach. We have a corporate product that hardly anyone uses because it’s slow, the search is horrid, and it has very rigid ideas around who can post what where.

Recently, a number of teams have started to use a different product, one they are finding to be far more useful then the corporate standard. Though it isn’t officially supported, it’s gaining quite a bit of traction throughout the organization. Imagine my surprise when an IS wide email goes out saying, in essence, that everyone should STOP using the product that’s working and contact the head of the crappy product team immediately so they can “migrate you over” to the “standard.” In other words, cease doing the thing that’s working, not “wow, we’ll fast track the adoption of this new tool since it’s serving such a vital need.” Makes perfect sense.

As I was reading the email, I thought of St. John’s (Go Johnnies!). Anyway, around the time my father was in school, they built the tundra dorms – named as such for the large open space between the bulk of campus and the dorms. Anyway, when they built the tundra dorms, they didn’t put in sidewalks right away, they waited until the students had worn paths and just paved those. Rather then guess what route residents would take, they let the property emerge. Needless to say, this approach worked pretty darn well.

The parallel here is pretty obvious – right or wrong, the “students” are wearing a path towards this new tool. Now I’m sure we can argue that the corporate standard can do “everything the new tool can do and so much more”, but the crowd has spoken. Instead of using scare tactics to keep people from using it, perhaps the bureaucracy would be better served by following the herd.

Categories: Off Topic, Rants, Software Tags:

Maybe Software Development IS Like Building a House

February 5th, 2008 6 comments

A few years back, my wife and I built a house. OK, so *we* didn’t actually swing a hammer; if you’ve ever seen me attempt a project around the casa, you know hiring the project out was the sanest course of action. This was my second go round with home construction, a process that many say they’d never repeat. But hey, I’m a glutton for punishment so in we plunged! I’d mostly walled off the entire experience in that place we put painful events like child birth and two-a-day practices, but last week one of my projects got me thinking that maybe, just maybe, there’s a comparison to me be made between house construction and building software.

Before I get started, I have to consider whether I’m on shaky ground here – many people have written pieces questioning the whole construction analogy. For starters, my friends Neal Ford and Glen Vanderburg have their takes with building bridges without engineering and bridges and software. Jack W. Reeves’ classic What Is Software Design? is a must read and Reg Braithwaite has a great post about what he admires about engineers and doctors which has this money quote:

Try this: Employ an Engineer. Ask her to slap together a bridge. The answer will be no. You cannot badger her with talk of how since You Hold The Gold, You Make The Rules. You cannot cajole her with talk of how the department needs to make its numbers, and that means getting construction done by the end of the quarter.

Considering the shared experience behind that impressive collection of wise words, I’m questioning my sanity to even think a construction analogy might fit software. But, even though I’m conflicted about the whole thing, I’m still going to share. Heck, maybe I’ll learn something in the process.

When we built our house, we spent several weeks looking at model houses, poring over floor plans, looking at carpet samples – all sorts of fun stuff. Now, with the last “home project,” during the requirements gathering phase we were just focused on the big issues: do you want a built in here? Would you like a fireplace? How about a skylight here? You know, the stuff you’ve got to get right before the foundation is set and the walls are up. At various stages, I’d get a call from the project manager (yep, that was his title, I’m feeling more confident already!) and he’d setup a time for me to come out to the site and work with one of the trades on issues like outlet placement. With my sample size of one, I expected a similar (iterative) process this go round – alas I was wrong.

You see, this builder had a different approach. They believed heavily in making all (and I mean ALL) the decisions up front (can you say BDUF?) Being a software geek, I think I do a pretty good job of thinking abstractly but needless to say, it can be quite a challenge to figure out where you want your phone jacks when all you have to go on is a 2D model of your future dwelling. I pushed back on the builder and was told they did this for a reason – they felt that if everything was on the plan, I could go on (as they put it) a four month vacation and come back to a completed house *exactly* as I intended it to be.

As much as I wanted to believe the people I was about to give a very large check to, I wasn’t convinced and as you might expect, my wife and I were on site pretty much every other day keeping track of what was going on. It was a good thing we were vigilant customers constantly running our acceptance tests. Nearly every visit revealed something that needed to be fixed, a story to be added to the backlog (or punch list in this case.) Some things were minor – a switch not controlling the proper light or a misunderstanding about what the plumbing code would allow. But others were, well, of the show stopper category. For example, despite a very clear floor plan showing where the washer and dryer were to be, the plumber decided he’d just put the washer where it was in every other house. Thank goodness we caught it early but this whole “we get it on the plan thing” certainly didn’t work in practice.

So what the heck does this have to do with software? Well, one of my projects has a customer group that thinks like my builder – they want to give us all the requirements, we give them an estimate, then they don’t talk to us until the project goes live. Obviously, this doesn’t work too well. I’m not sure why people ever thought this approach worked, heck, if we can’t get it right with houses (something we’ve been building, oh, forever) how can we possibly get close with a discipline as new as software? No, the answer is found in an agile approach where we work closely with our customers. Does that mean we need to see them for eight hours a day everyday? I sure hope not, but if they aren’t willing to commit some time to the project, how important could it actually be?

Needless to say, we’re trying to get the customers to think different, to embrace a more collaborative approach and I hope we succeed. Otherwise, I have a pretty good idea what will happen after that four month vacation.

Categories: Agile, Development, Rants, Software Tags:

You say Hacker…

January 4th, 2008 No comments

You’d think after the hubbub over Sony’s rootkit problems of 2005, companies would know better but apparently Sears has decided that “community participation” has a very special meaning. I have no idea how any company could possibly think this was a good idea… BTW, if you’re not reading Schneier on Security you’re really missing out.

Categories: Rants Tags:

google