DaedTech

Stories about Software

By

Signs Craftsmanship May Be For You

One of the things I’ve spent a good bit of time doing over the last year or so is called “Craftsmanship Coaching.” This involves going into teams and helping them adopt practices that will allow them to produce software more reliably and efficiently. Examples include writing automated unit and acceptance tests, setting up continuous integration and deployment, writing cleaner, more modular code, etc. At its core though, this is really the time-honored practice of gap analysis. You go in, you see where things could be better, and you help make them better.

Using the word “craftsmanship” to describe the writing of software is powerful from a marketing perspective. Beyond just a set of practices revolving around XP and writing “good code,” it conjures up an image of people who care about the practice of writing software to the point of regarding it as an art form with its own sort of aesthetic. While run-of-the-mill 9–5ers will crank out code and say things like, “if it ain’t broke, don’t fix it,” software craft-people will presumably agonize over the smallest details, perfecting their code for the love of the game.

Friendlies

The drawback with using a term like “software craftsmanship” is the intense subjectivity and confusion of what exactly it entails. One person’s “well crafted code” might be another’s spaghetti, not to mention that subjective terms tend to get diluted by people wanting, merited or not, to be in the club. To understand what I mean, consider the practice of scheduling a daily status meeting, calling it “daily Scrum,” and declaring a shop to be “agile.”

How then are software developers who are not associated with the software craftsmanship movement to know whether they should want in or not? How are they even to know what it is? And if they don’t easily know, how are overhead decision makers like managers to have any clue at all? Well, let’s momentarily forget about the idea of software craftsmanship and return to the theme of gap analysis. In the rest of this post, I’ll describe signs that you could stand to benefit from some of the practices that I help clients with. If you notice your team experiencing these things, the good news is that you can definitely simplify your life if you pursue improvements.

Similar Features Take Longer and Longer to Implement

Remember a simpler time when adding a page to your site took a few hours, or maybe a day, max? Now, it’s a week or two. Of course, that makes sense because now you have to remember to implement all of the security stuff, and there’s the validation library for all of the input controls. And that’s just off the top. Let’s not forget the logging utility that requires careful edits to each method, and then there’s the checklist your team put together some time back that you have to go through before officially promoting the page. Everyone has to think about localization, checking the color scheme in every browser, and so on and so forth. So it’s inevitable that things will slow down, right?

Well, no, it’s not inevitable at all. Complexity will accrue in a project as time drifts by, but it can be neutralized with carefully considered design approaches. The examples that I mentioned, such as security and logging, can be implemented in such a way within your application that they do not add significant overhead at all to your development effort. Whatever the particulars, there are ways to structure your application so that you don’t experience significant slowdown.

Simple Functionality Requests Are Anything But Simple

  • “Hey, can you change the font on the submit button?”
  • “Not without rewriting the whole presentation layer!”
  • “I don’t understand. That doesn’t seem like it should be hard to do.”
  • “Well, look, it is, okay? Software is complicated.”

Have you ever participated in or been privy to a conversation like this? There’s something wrong here. Simple-seeming things being really hard is a smell. Cosmetic changes, turning off logging, adding a new field to a web page, and other things that strike non-technical users as simple changes should be simple, generally speaking.

While clearly not a universal rule, if a vast gulf routinely appears between what common sense says should be simple and how hard it turns out to be, there is an opportunity for improvement.

Until Next Time

I originally wrote this post for the Infragistics blog and you can find the original here. There is also a second part to this post, as well.

newest oldest most voted
Notify of
Andy Bailey
Guest
Andy Bailey

This has caused so many harmonics at so many wavelengths with me. I approach software not as a craft but as a science and use the scientific method, where appropriate, accordingly. I try to design with the future in mind: the motto being “my code is going to be extended by others in the future”. I have the distinct pleasure of working in an otherwise very young team of developers. But part of the price to pay for that is helping them break the habit of “doing enough to get today’s code working” as being a goal. Their argument is,… Read more »

Erik Dietrich
Guest

I’ve thought on various occasions about how to have developers leave school more cognizant of the importance of keeping code relatively easy to change. Not that I think it’d be easy by any stretch, but there has to be something to improve the situation where they’ve never even thought about it.

Andy Bailey
Guest
Andy Bailey

Create a software project that is built on in each year or continuation of the academic course the student is involved in. Part of the grade given for each iteration should be based on how little code from the previous iteration has to be changed in order to complete the goals in this iteration. Make sure that necessary changes to the base code are provided so as not to penalise the student for this. The initial project code should be horrible and require a thorough refactor, the student is introduced to code smells, patterns, doggerel like SOLID, DRY, YAGNI and… Read more »

Erik Dietrich
Guest

I like it 🙂

Kevin O'Shaughnessy
Guest
Kevin O'Shaughnessy

This is a great idea Andy. I would love to see university’s design a CS course this way. Of course this means the University would need to pick one language and stack and stick with it for at least three years.

It would be difficult to mark refactoring work in an objective way. The University might need to spell out the whole grading system in advance in order to be fair.

Employers hiring graduates also need to appreciate that having the skills you mention is far more important than having X months experience in the latest hot framework(s)

Pattern-chaser
Guest
Pattern-chaser

Good article, but this confused me: “Simple-seeming things being really hard is a smell.” Sometimes, something the *user* might expect to be simple, isn’t. [Sometimes the opposite.] That’s why it’s so important to *talk* to our customers, yes?

Erik Dietrich
Guest

I’m using “smell” in the sense that it probably, but not definitively, indicates a problem. In other words, if you encounter a “smell,” you should investigate, but not necessarily conclude that a problem exists.

So, if something seems like it should be simple but it isn’t, there *might* be a reasonable explanation. But there’s a good chance the explanation is “we’ve made a bad design.”

But yes, absolutely, you will not know without talking to the customer, so do it!

Pattern-chaser
Guest
Pattern-chaser

No design can or should deal with every possible combination of events the universe can throw at it. Its complexity would approach infinite size. To cut ideas down to something that can be practically implemented, we assume some things are likely, and others unlikely. If we get unlucky, a new feature request will clash with something our design had classified as unlikely. Is this a bad design? Well, hindsight shows that at least one particular guess (that X was unlikely) was wrong, but bad design? I don’t think so. In a sort of bayesian manner, we now have new information… Read more »