Entries Tagged 'Software Development' ↓

My first desktop PC didn’t much resemble the PCs of today.  It was a TRS-80 Color Computer II, with 16K of RAM, a single cartridge slot, and two joystick ports.  If you’re like me, you also had a computer like this one — maybe a TI-99/4A, a Commodore 64, or a PET.  Chances are, it booted into an interpreted BASIC command line prompt.  For many of us writing software today, our first experiments in software development came from looking at the prompt and wondering, “What can I do here?”

photo credit: Extra Ketchup. This is not me … but it practically could be!

Continue reading →

I got a great email last week from my colleague Susan Shapiro, who works with the EMC Community Network.  The EDN (EMC Developer Network) is organizing a coding challenge for EMC World 2010, with a respectable amount of prize money ($25K total split among several prizes) at stake.  Being the self-centered guy I am, I immediately confirmed that EMC employees were eligible (they are, but only for one of the prizes) before letting myself get excited.

The concept: write a project where multiple EMC developer technologies can be used in a single program.  Bonus points for incorporating other online technologies.  Win money and fame and the adoration of the world.

I’m waiting for the detailed T&C, but you can read up more on it here.  Innovation through contest is something EMC has tinkered with quite a bit, as you may have read on Steve Todd’s blog last year.

Definitely check out the link for more info. I’m hoping I can find some time in between all my “real work” to put a couple of these tools through their paces.

You’ve probably heard a variation on this statement from a software developer, made in jest, but containing a nugget of sincerity:

It was hard to create, it should be hard to use (or maintain).

Basically, we worked hard to get this stuff done and we expect you as a user or future maintainer to put the same effort into it.  After all, it took many man-years to write the software, it’s not too much to expect you to spend a few weeks reading manuals and understanding it before you start complaining that it’s hard to use.

As Paul Young recently wrote, though, imagine if wood-chippers took that approach.

Imagine if an author did?  “It took me years to write this novel, you should have to do some research before you read it.”

Some do, I guess.  I’ve read a few novels that require major work to get through.  Sometimes the end result is even worth the work.  But as my fiction writing friends tell me, in general you don’t want your readers to be thinking about your writing, you want them thinking about your story.  Similarly, you don’t want your users thinking about your software design, you just want them thinking about the task your software enables.

I feel the same way about maintaining and testing software.  We want developers thinking about the code, not about the way you wrote it.  You don’t want someone looking at your code, peering at it for a few minutes, and then saying, “Oh, I get it.  Wow, that’s clever.”

There’s a famous quote attributed to a half-dozen different writers (and perhaps originated by Blaise Pascal), that says, basically, “I am sorry I wrote such a lengthy letter; I did not have time to write a short one.”  It takes time to create simple, elegant software.  When we force the issue and compress the time spent on a project, you end up with complex code and complex user interactions.  We should consider this a problem, not a point of pride.

When we present some difficult software to our users, we should apologize to them.  “I’m sorry this UI is so complex.  I didn’t have time to make it easier.”  Instead, we make them feel guilty.  “Ah, perhaps you should have taken the training,” or read the manual more carefully, or attended our seminar.

Think about the people on your team, and ask yourself if they “get” this concept.  Realize, that if they don’t, you’re eventually going to lose your market share to a competitor who does.

I’ve written before about how we can’t afford to be religious about our science.  I’m seeing that situation in a new light based on some experiences while working on our Next Big Thing here in Ionix Storage Resource Management.

Continue reading →

If you look up dogma on wikipedia today, you’ll see this phrase as part of the definition: “It is not to be questioned.”  Software developers are at their core scientists, however, and scientists are defined by the fact that they ask questions.  So it should be obvious that there’s no room for dogma in your software group.  And yet, go down the hall to a few of your more senior developers and ask them about coding standards, development practices, or even IDE preference.  Good luck.

Continue reading →

I’ve been thinking a bit more about the topic of my previous post (deadlines forcing decisions and focus), and comparing it to some other moments of high-energy, high-engagement, high-satisfaction productivity over the years.  I realized there was a factor I hadn’t really considered before, and that was the capacity of the task to force all participants to remain in the moment.

Continue reading →

A pressing deadline is a powerful thing.  Without a deadline, ideas can drown each other competing for supremacy in a sea of data.  People use and abuse their own value functions to find fault with any possible approach.  But faced with a deadline, thinkers break out of analysis paralysis and become doers.  Of course, an unrealistic deadline just causes panic and sloppy work as people scramble to meet impossible goals and push themselves deep into technical debt.
Continue reading →

Sorry Napster fans, I’m talking about a different kind of P2P here … career development in a peer-driven context.

In nearly every group I’ve joined, some bright developers eventually banded together and decided they were frustrated at feeling out of touch with the industry.  The answer has always been some sort of peer-driven career development effort.  For example, back in the late 90s, I remember we set up a regular meeting which the entire Navisphere development organization was invited to.  Each week (or was it month?) a speaker would present on something new they had learned.  Occasionally, a guest speaker from another organization would present on something they were doing.  The speaking responsibility rotated among volunteers until we realized it was basically the same 3 people over and over again, and it fizzled out.

Continue reading →

“He who is not courageous enough to take risks will accomplish nothing in life.” – Muhammad Ali

I’ve written in the past about how we need to embrace and even seek out risk at times.  Since I used American Football to discuss the topic before, I thought I’d continue the discussion with an example of poor risk management from this past weekend’s games.
Continue reading →

One of the common complaints you hear in Resource Management Software development is that you’re not working on anything Cool.  There’s just something pedestrian about writing software that (at its core) monitors hardware.  I mean, there are exceptions, some stuff that we do is really cool, but it’s seldom capital letters Really Cool, like, say, VMware.  Or video game development (which I imagine is fairly pedestrian in itself, but at least has an output which your average in-law can appreciate).

But yesterday I sat in on a meeting about something that is Pretty Cool, if not Really Cool.  And it’s not even software.
Continue reading →