Entries Tagged 'Software Development' ↓

I wrote some time back about how we all write throw-away code, how applications have life spans and you don’t want to work on the same code for two decades. Recently I was discussing this topic from a slightly different angle, in terms of how a product team’s technical culture has momentum and how important it is to be able to shift that momentum over time. I speak here of the collection of tribal wisdom and best practices that influence the technical decisions of a team over time, the technical values that the primary decision makers rely on when steering the ship.

Continue reading →

Recently, I took the Certified Scrum Product Owner class with Angela Druckman.  Angela was an excellent teacher and brought some new perspectives to me, and everyone in the class.

My organization has been using Agile/Scrum in one way or another for several years now, and much of the class felt like a review.  But, as the class went on, I realized just how much we had modified “textbook” Scrum to fit our needs, and it gave me some interesting moments of introspection relating to what that tells me about our organization and the way we do business.  That may not be the value most people expect in taking a class, but I tend to find that the biggest wins from formal training aren’t usually in direct addition of knowledge (“I know Kung Fu“), but rather in being forced to think about things in new ways, or in the side conversations you have the luxury of having since you aren’t at your desk focusing on getting something done.

Continue reading →

This year, I’ve had two different occasions where I had to work with team members who had invested significant amounts of time into developing features which ended up not being included in our shipping product.  This wasn’t prototype code, this was code we fully intended to ship while it was under development, but chose not to for business reasons.

As I got ready to break the news to the team, I remembered the first time that happened to me as a developer, and how frustrated I was.  You think back on the weekends you worked to hit deadlines, the hours you spent trying to find tricky bugs, the wars you went to over design philosophy, and you wonder if any of it was worth it.

Continue reading →

Releasing a product is one of the hardest jobs we have, as creators of software.  Developing a product is a potentially never-ending process; there are always new features to be added, bugs to be fixed, and test configurations to validate against.  A release date pulls the team together, an often-moving deadline to strive against as an organization.  Everybody pulls out all the stops, developers and testers work through nights and weekends, technical writers come out of the woodwork to keep documentation updated, and the leadership team meets daily to ask the question: “Is it done yet?”

The question, of course, is really “is it done enough yet?”.

We finally shipped ProSphere 1.0 at the close of July.  I am not surprising anyone when I say that wasn’t the first release date we had in mind, nor am I surprising anyone when I said we shipped with a backlog of items we wished had made it into 1.0.  But at some point you need to ship it and move on.

Today I have a slightly different team; a few people have changed responsibilities to allow the teams to better meet the needs of our next release.  And while I work to integrate that new team together, I also stew over a laundry list of requirements and enhancements to our product for the next release.  Resolving priority conflicts, providing gross estimates, learning new areas of the product, and making sure nothing slips through the cracks — it’s a busy time.

It’s a totally different kind of busy than when trying to release a product — but it’s just as important.  The context shift is jarring, but the quality of the work done today will impact our working lives for the coming months, and have a direct impact on the satisfaction of our customers with the next version of this product.

This is, of course, the job we all signed up for.  It’s an exciting time.

In 1996, I joined the CLARiiON team to work on a new Storage Resource Management product. It was a management software leap to go along with the leap forward from SCSI to Fibre Channel. We looked at everything that was “wrong” about the existing solutions, took into account new requirements based on the scalability of the new hardware, updated our products to use the leading edge technologies, and created something entirely new – Navisphere. It was a huge splash for CLARiiON, and helped define everything I think of as successful in a software project.

Fifteen years later, I’m writing about a new big splash for EMC in the SRM space – ProSphere 1.0. I’ll stop you right here and tell you that you need to go read Chuck’s post on the product. I can’t out-do his deep-dive into the industry angles and why it’s such a big deal, so I won’t even try.

What I will tell you is why working on this product was so different from any other product I’ve touched at EMC, and why I’m so proud to be able to announce it here. Just like fifteen years ago, it was a chance to take a look at everything “wrong” while also still looking in new directions at the same time the industry is making another scale leap with Cloud environments. This has been some of the hardest work I’ve done here at EMC. But seeing it get out the door is making it all worth it.

Continue reading →

… get an important answer.

Two colleagues of mine demonstrated to me today a habit which, on its surface, can be difficult to understand.  They really enjoy asking the stupid questions.  We’ll be in a design review, looking at a fairly straightforward diagram showing a few components interacting, and they’ll ask what customer use case this represents and what those components are.

We all know the answer.  It’s fairly obvious. But the person writing the design didn’t label the components and left it open to interpretation.

My first instinct was to jump in, say it wasn’t important, that we needed to get to the guts of the design to review it.  I was wrong.

Continue reading →

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 →