Product Maintenance

Ah, product maintenance:


Working with talented people who are constantly learning is amazing. Thinking that every piece of code that is even slightly aged is incorrect or wrong is not as amazing.

Compromise is a skill. And not one that we only use with clients. 🙂

Master the basics first

Very good advice:

Until you can reliably deliver what you thought you could deliver, focus on how you define and build software. You don’t need Lean or Kanban or to improve your stand-up meeting. You need to learn how to define, build, and deliver software.

Don’t be distracted by nuance if you can’t get the basic gist correct. Deliver what you say you will deliver. And only work on that until you can do it. Be functional first. And then work on refinements.

The cost of gaining knowledge

Somewhat cynical, but amusing:

Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.

There’s never enough time, right? This world moves so fast. Even if a client had granted unlimited time to produce something (I can hear you laughing. Stop it.), the technology changes so fast that as soon as you build something, there is already a better way to do it. By the time you build your fourth feature, you already want to rewrite and optimize the first one you built.

But beyond the speed of technology, it’s just the cost of gaining knowledge. The more you know, the more you realize what you’ve done before could be better. It’s an awesome monster that we feed with every step. The faster you learn, the more the past haunts you. The refactoring monster is on your doorstep. Would you want it to be any other way?

I wouldn’t. The adventure of learning and exploring is worth the potential regret that we can’t refactor everything behind us.

Onward.

Regulating development

An interesting post on the Ken Schwaber blog:

Our  shortcomings were surprising to me. When I rolled out Scrum, I thought that the excellent developers that had been stifled by waterfall processes would emerge, and we would again do great work and build great software. Much to my surprise, many never had those skills or had lost any skills they had. The pressure of “get it all out now, cut quality to do so” had reduced most developers to unskilled, unprofessional, angry drones. The larger the organization, the worse the situation as “mediocrity scaled.” Organizations whose software is only five years old are already crippled by technical debt.

He posits that governance of software developers is imminent – whether the industry elects to self impose these guidelines or the government demands it – and that formal regulation of skills and capabilities is needed.

It reminds me of my real estate days – an industry with a very low barrier to entry, and an extraordinary range of practitioner proficiency.  (Sound like software development to you?  Yeah, to me, too.)  There is a plethora of “certifications” that are intended to provide proof of an agent’s skill.  A Certified Residential Specialist?  How about a Graduate of the REALTOR Institute?  When working with an agent with a set of fancy letters after their name, did the transaction proceed more smoothly?

Not generally, no.  In my experience.  They’re generally pay to play: read the handout, sit in a chair and exist for the required number of hours, pass a simple test, pay the man for the honor of putting the letters after your name for a year.  Clearly, this is not the model to adopt.

This, however, is certainly a problem:

If I were on a team, I wish that I knew the level of the developer that I was bringing on board, instead relying on personal references and “the usual suspects” to avoid getting swamped by unfounded braggarts.

I don’t personally believe a governance board can replace screening candidates for my personal standards for proficiency.  Might it give me some warm fuzzies that the candidate has at least tried to gain a skill?  Possibly.  But in a world where even a college degree is seen as optional, an archaic proof of capacity, what can a governance board provide?

It’s an interesting thought.  Can you regulate development processes across an entire industry?  Can anyone really certify skill, if proficiency is a relative determination?  Things to ponder.

Being proud of ugly babies

Every once in a while, we finish something we think is awesome. Shiny. Spectacular. Perfect in every way. A tiny little flawless newborn code-baby, clearly demanding your adoration and unbounded love.

And then the client doesn’t like it. “Take that head off,” they say. “Paste it to the stomach, and then put both arms on the same side.” “Can we make it more monochrome? And there’s no reason for five toes on each foot, we only need seven toes, total.”

Agency work can be tough, sometimes. We want to be proud of our work, we want to build awesome things. And sometimes, we have to build what we think are monsters.

That’s okay though. Opinions are like, uhm, belly buttons. Everyone has one. And clients are always going to have their own. They are entitled. It’s their money and time and product, after all.

I do believe we have the obligation to advise when we see clients turning down the road to creating monster babies. We may have expertise, and I believe we have the responsibility to advise and inform. But ultimately, though we are building this thing, it is not ours. It is theirs. It is their right to not agree with us.

Perhaps we can take pride, instead, in our process. In the ability to build a great *anything.* To make happy clients. To enjoy the opportunity to shape a product, even if we are not the final decision makers. To enjoy and welcome the diversity of opinion.

…even if we do think that’s the ugliest baby we’ve ever produced.