Chris Johnston

After reading Dan North’s post on the Manifesto for Software Craftsmanship entitled “Programming is not a craft” and Liz Keogh’s post, “Why I didn’t sign the Software Craftsmanship manifesto“, it got me thinking about what is the point? What is it that we should be doing as software developers?

Is the point of software development to create clean, aesthetically beautiful code containing clever implementations to business problems or is the point to deliver working software? If you know anything about me then you probably already know what I am going to say, but, for those who are new, I will continue. I personally think the point is to deliver software. Everything else is how we do our job (well, except the clever part).

One problem with universities these days is that they teach people how to create programs. They do not teach students how to create software. When creating software, programming is probably the task that you do the least of. At least programming as it is taught in school. Developing software is about creating a solution that meets the user’s needs and solves their pain points. It is not about the cool heuristic you developed. No one cares about that stuff. They care about getting their work down and whether your software will help or hinder that goal. As such, you spend more time testing code, modifying old code, gathering and understanding business requirements, talking to other developers as opposed to sitting there and just churning out code.

Creating clean code that is easy to maintain and extend is how we go about reaching the goal of delivering working software; it is not the goal itself. I think this is the biggest mistake many programmers make. They mistake the process with the goal. And I agree with Dan and Liz that it is a pitfall for people signing the manifesto.

Now, don’t get me wrong, clean, maintainable code is important for the life of the software that is being delivered and your sanity as a developer. I am currently working on an application that was created by programmers, not software developers, and we are having to rip parts out and rework other parts in order to increase the application’s lifespan. So clean code is important and the goals of the craftsmanship movement are important, but they are the tools, not the product.

This is like a group of Doctors getting together and signing a manifesto for sterilizing their scalpels. Yes, it is important, and at one point in time, it was very much needed. But sterilizing tools was never the end goal, keeping their patients healthy and alive was the point and sterilization was only a means to that end.

If your goal is delivering working software then you only have time to code until it is good enough and test until it is good enough. There is no time to be clever or to make it perfect (there is no such thing anyway). Create the initial code using things like the SOLID principles and TDD, but in the end, if you haven’t delivered software to your client and stakeholders then you are not doing your job and you have missed the point.

One trick that I use when I can figure out an API or how to test something (like testing controllers that use AuthLogic) is to look for the particular method––in this case activate_authlogic––on github and look at how other developers use it.

One of the problems with tutorials and documentation is that it never shows how to test code that uses the gem. This was the case for me today with AuthLogic. I was having a hard time figuring out where to put activate_authlogic and the code for logging in a user in order to test a controller. A quick search on github provided more than enough examples for both RSpec and Test::Unit.

One problem I have seen on several projects I have been on, including my current project, is that the developers and the business stakeholders use different vocabularies when describing things. Eric Evans, in his book Domain-Driven Design, stresses the importance of having a shared vocabulary where the devs use the same language as business.

As an example of this, I recently had to make a change to my cell phone account. It was originally under my wife’s name and I had to move it so it was under my name. I went into a Roger’s store and attempted to describe what I wanted. The result was several strange looks. Eventually the sales person asked if I need to do a “Transfer of Responsibility?” To which I said yes. Immediately there was understanding between everyone involved. We were speaking the same language.

Having a shared language can be problem within a single application, not just between developers and business. The project I am working on right now contains a Person model that handles people. In the database, it has a People table. The problem is that every where else, we use the term Member and there are a few places where the term User is used. This makes working on the code confusing along with trying to describe it other developers and business.

The solution, contrary to what developers believe, is to learn the language that your clients and stakeholders use. They are the domain experts and they are the ones who will eventually use the application your are building. As such, one of the best methods of guaranteeing that you build the right solution is to learn the language of the domain in which the problem you are solving resides.

The biggest advantage of doing this is that it allows the developers and the users to have intelligent conversations without one group having to translate. Everyone know what everyone else is talking about and it allows decisions to be made quickly and for problems to be found and understood quickly.

Imagine a scenario where you have two developers discussing a particular user story. The discussion is over a bit of confusion and ambiguity in the story. A business user walks by and overhears the two developers talking. Instead of walking past, shaking his head at the foreign language the developers are speaking in, he is able to jump in and point them in the right direction. The reason is because he understands what they are talking about. Additionally, the developers very quickly understand the solution provided and don’t need to translate it.

In short, I believe that a non-developer should be able to sit down at a developers computer and start reading and understanding the code in front of her. The reason is that the objects, methods, and classes should all reflect the language of the domain. They may not understand the syntax or logic, but they should recognize the operations, names, and language as their own.

One of the things that I am passionate about is the need for applications to be both usable and aesthetically pleasing for the people using them. If your application does not meet these two requirements then, in my opinion, you have failed. This means that every development team needs UX people. Or as Michael Feathers’ puts it, “To put it more boldly: it’s not that development teams need UX people, it’s more like UX teams need developers.”

Michael Feathers has written a blog post relating software development to cooking. In it, he asks the question, “Where are the high-end restaurants of software development?” His answer is that they are in the smaller boutique development shops popping up around the world. The shops that adhere to the ideas behind the Software Craftsmanship movement.

In this article, he also states that in this day and age, UX is the defining aspect of developing applications and those teams that do not understand that developing software is all about the customer are doomed. I can’t agree more with this idea. The only thing that matters to a customer of your software is how easy and pleasing is it to use. We as developers can no longer have the attitude that we will create software and, well, the users will just have to learn how to use it. Everything we do needs to be customer and user centered.

Michael also puts forth the idea that as developers we need to learn how to do UX and be able to use those tools when called on. We don’t need to be experts in design or layout, but we should have a shallow understanding of the principles and how to apply them when sitting with a customer.

I want to take this one step further by saying that I think UX also has a responsibility to share their knowledge with developers and have them present during every stage of the UI development process. Just as it is wrong to have developers who know nothing about usability, it is just as wrong to have UX people who do everything in secret and then simply hand developers a design expecting them to implement it.

We need to tear down this curtain that exists between developers and UX and work needs to be done on both sides. One of the best projects I ever worked on involved developers working with designers and UX people creating wireframes and doing lo-fi prototyping with the users throughout the entire development process. Everyone on the team owned the success and failure of the application and in the end we created one of the best apps I have ever worked on. We were able to create an application that the users were excited to start using.

I have also worked on teams were the UX team showed up to standups in the morning and then handed designs to the developers. There were no discussions on whether something was implementable and there was no insight into where the designs came from. For all I know they outsourced the photoshop work to penguins in Antarctica. How can the team own the entire application if one part of it is created in isolation?

If you are passionate about creating software applications that can actually be used by people and passionate about the quality of those application then go read Michael Feathers’ article.

A few days ago, some software developers got together at 8th Light and created the Manifesto for Software Craftsmanship. If you are a professional software developer who cares about the code you are creating, then you have a responsibility to sign and adhere by the principles laid out in the manifesto.

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

For a better understanding of what this means, check out this video of a presentation that Robert Martin did on Craftmanship and Ethics.

One thing I have been thinking about lately is who owns, or should know about, tech tasks. The team I am on right now, we need to justify every tech task we do with business and if business value for that task cannot be found then it doesn’t get done.

For some reason, I really don’t like this approach and for the first time, I have read a blog that expresses what I have not been able to as of yet. John Pither calls this tech leakage and explains it as such:

If we can see the dev team as an animal in the jungle (and so forth we have other ‘animals’ such as QA teams, BA teams, Project Managers etc), then ‘dev team leakage’ refers to the cutting open of such a large and volatile jungle beast and of letting it’s gooey entrails slide out and slither amongst the wider natural setting of which the poor animal finds itself.

Yep. Basically it’s about breaking encapsulation. In the case of a dev team, there are many inner workings that need not be externalised to the outside world.

As graphic as this analogy is, I really like it (okay, I have a morbid sense of humour). Tech tasks should belong to the dev team and simply be a part of how we do our day to day jobs. I find that I spend far too much time explaining why I am doing a particular refactoring to a BA or business because the team does not own these tasks. In addition, far too many tasks never get done because we cannot justify them with business value.

One consequence of this anti-pattern is that nothing really comes out of retrospectives. Yes, do them every week, however, every action we create must first be justified with business and given some business value before we are able to carry it out. This means that we never have the chance to clean house and carry out those dev tasks that we should be doing as a part of our jobs.

One practice that I have observed that seems wrong to me is re-estimating cards after they have been completed. The dev pair completes the story card and the BA comes over and asks them to re-estimate the card based on the implementation.

From the BA’s point of view, s/he is asking for the re-estimation for planing purposes. The reason given is so they can accurately plan out the stories for the next iteration. On this same project, there is also a lot of talk about correctly estimating cards. To me, this completely misses the point of estimating cards.

Story card estimation is a best guess of either the complexity, the story card size, or the ideal days needed to implement the card. That is all. This means that the estimations are inherently wrong. The point though is that they will be consistently wrong and over time, with the addition of velocity, the amount of work a team can get done will be correct.

If a team consistently underestimates, then the first iteration they will do more cards then they committed to. The velocity will show this and can be corrected the next iteration. So the first iteration they commit to doing 12 points and they actually do 15. The next iteration, simply select 15 points worth of story cards. Rinse and repeat.

By asking devs to re-estimate cards once they are completed you are breaking the corrective effect that velocity has on the process. The points on the cards carry less meaning because they have been adjusted after the fact. This means you now need to add a correcting feature into the teams velocity.

The team committed to doing 12 points and completed 15 points, but two of the cards they originally committed to doing were actually 1s and not 3s so did they in fact do 15 points or 19 points? So which cards for the next iteration are going to be re-estimated down and which cards will go up? Does this mean that the team should be doing 15 or 20 points for the next iteration?

My guess for the re-estimation requests is that the BAs do not trust the process. They do not believe that velocity will naturally add the needed correction. So instead, they try to do it themselves. In addition, on this particular project, I also think that business is trying to add to many features during a single iteration and the scope is just too large.

I think there is a time and place for re-estimating a story card, but after the card has been played it not one of them. If, before playing a card, more information becomes available that directly reflects the implementation of a card, that card should be re-estimated. This might include the outcome of a spike or the introduction of a new technology or a change in the development team for instance. The point is that this happens before a card is played, not after.

What do others think, can a story card’s estimate be updated after it has been played?