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 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.

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.

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.

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.

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.

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?

I should have nothing to complain about, and yet, I do. However, I would like some feedback on my complaints. I think the team could be doing things better and would like some other opinions on a gripe that I have.

We have a practice of kicking off stories before a pair can begin work. This involves getting the BA, the producer (the business representative), the tech lead, the tester, and the rest of the team together to discuss a single story that a pair is about to work on. The reason that I have been given for this is that stories change too quickly and frequently and, therefore, cannot be reviewed any earlier then just before the pair begins work.

People are busy though, especially the business representative, and thge pair ends up sitting around waiting until everyone is available. A few of us have put forth the idea of doing a kickoff of all the stories committed to for an iteration during the iteration planning meeting. Then simply letting the pair work on the story when they get to it. If there are changes, it is the devs responsibility to read the story and discuss those changes with the BA and business. The conversation shouldn’t end just because everyone has done a kickoff.

Management, however, squashed this suggestion pretty quickly for the reason stated above. My take is that they don’t trust the devs to properly read and implemented the story. Which brings us to walk through.

Walk throughs happen after a story is dev complete and once again involves the BA, the producer, the tech lead, the tester, and the pair. Everyone goes through the story, dissecting it to ensure that it has been implemented correct. The pair cannot work on anything else until the walk through has been done. In the end, this means that the devs have to wait for everyone to be available.

The interesting thing is that even with all this scrutiny, I am not convinced that it results in any less bugs or better code. As far as I can tell, it simply wastes everyone’s time. The amazing thing is that the team continually votes to keep kickoffs and walk throughs as part of the process and adds things to make then either longer or harder to perform.

I can see value in each of these practices. Once you have completed a story, it is nice to have another pair of eyes take a look and double check that you haven’t missed anything. And before you start, it is important to have that conversation with the BA and business in order to clarify exactly what it is that they want. Both of these are vital parts of software development.

I think the part that bugs me is the lack of trust that is implied by the way the two practices are carried out. I feel that as a dev I am assumed guilty until proven otherwise. Until I can repeat back to the BA and producer what is written in the story, I am deemed not worthy to begin work on it. Likewise, until the business, BA, and tech lead have all signed off on a story, it is deemed incomplete simply because it was implemented by a developer. Or I could be reading to much into things.

Other devs have also commented on the lack of trust they feel due to these two practices, so I don’t think it is just me. But how do you go about changing this kind of culture? And is it even worth changing? It gets frustrating when these issues come up in retro and either management simply says no or the rest of the team votes to make them even more complicated and time consuming. I am not sure how to change an entire teams mind, especially when it seems to most people that it is working fine.

I was in a retrospective today where the importance of the build seemed to focus more on the artifacts. We were discussing pipelining our build and the discussion centered around breaking the build down by artifacts as opposed to areas of feedback.

Personally, I find this a little strange. The last several projects I have been on, the various builds we had were all about providing feedback as quickly as possible. To this end, the first build ran unit and integration tests, the second build ran all the functional tests (think Selenium), with other builds running more in depth functional and acceptance tests.

To quote Martin Fowler, “The whole point of continuous integration is to find problems as soon as you can.” To me, this sounds like information and feedback, not artifacts.

My question to the greater, and more experienced, community is what do you think, should pipelining a build be about artifacts or feedback or a bit of both? Currently, one of our builds takes 2+ hours and we are looking to cut that down. I am not sure we can do this if we concentrate on artifacts instead of feedback. What do others think?

C# 3.0 is a really nice language. It seems to have gotten generics correct making for some really nice code, especially were the database layer is concerned. We are using LINQ to SQL and we have been able to implement a single class for the repository which works with whatever model object type we give it. I also really like the inclusion of Lambdas and delegates, which make for some very clean code constructs and are much cleaner then anonymous methods in Java.

The second new technology to me is ASP.NET MVC. This allows us to do ASP.NET without actually using ASP.NET. Currently, it is still in preview releases, but it is definitely heading in the right direction. Everything (with the possible exception of views) is completely and easily testable. This means no more having to hide functionality behind presenters or controllers and hoping it works in the code behind. Controllers are completely testable right down to testing what views or redirects they return.

The last new thing I am using is jQuery. I fully understand why it is becoming the defacto Javascript library. To do most things only require a few lines of jQuery Javascript and its AJAX and JSON capabilities are incredible. One nice thing about ASP.NET MVC is that it is capable of returning JSON results with a single line of code. This makes working with jQuery seamless.

If you are starting a new .NET web project, definitely check out ASP.NET MVC, C# 3.0 and jQuery. If you are new to C# 3.0 then check out the book C# in Depth. It highlights all the changes since 1.1 in a nice concise format that will bring you up to speed quickly.