Software Craftsmanship

Software craftsmanship is hot topic which has been on the rise for quite some time. As it often goes new things are full of buzz and hype. As with all hypes people start to attach wild images and stereotypes on them. Fortunately there are smart people out there shedding some light upon software craftsmanship.

Dan North wrote an excellent blog addressing the issues that the software craftsmanship movement has and will generate if we are not careful. I do not share Dan’s fears though that the software craftsmanship movement will fill up with wannabe‘s and primadonnas. In any case they will be weeded out very fast. Wishing  to be good takes you only so far and when you have to deliver according to your promises, well…

Jason Gorman, in his blog, provides another view upon software craftsmanship. His ideas are more close to the idea that I have about the software craftsmanship and the software craftsmanship movement. An integral part of it is to satisfy the customer. To me software craftsmanship is simply a synonym for “do what you promised in a way that makes you proud “. It implicitly also means that I am always on a journey to become better. I want to become better so that I can make better software. Continuous improvement gives the tools to meet customer needs with a level of quality that satisfies myself and allows me to be proud of my work. Without continuous improvement you can’t be a craftsman. It also means that in order to be good I have to deliver the right thing. Not just excellent code but the right code. But this is nothing new, to quote Jason Gorman “Software craftsmanship’s not the “next big thing”. It’s an attempt to articulate what the “thing” always was“.

As I see it, software craftsmanship requires at least the following:

• Continuously cultivated skills
  • achievable only with continuous improvement(Jason Yip put it nicely “Talent doesn’t determine how fast you get good; how much and how well you practice determines that“)
• A positive attitude towards work
  • don’t just criticize, offer alternative solutions
  • do the boring jobs also with 100% effort
• Humility
  • humble attitude is a must, we create software for others
  • we can’t ignore our customers, instead we must cherish them

Now, it is up to you to decide whether working from 9 to 17  as a generic programmer is enough for you or is there more to it… Just remember that there are no shortcuts nor 2-day courses to get a certificate. It is a lifelong journey.

I already made my choice, I want to be a software craftsman.

ps. get more of software craftsmanship @ Scandinavian Agile Conference 2011!

Best Practices – Another Silver Bullet?

Recently I had a short but intense discussion in Twitter with Ari Tanninen about best practices. Best practices have been haunting me for a while so I came to the conclusion that I need to write a blog post about them.

First things first., I have one very profound problem with a thing knows as Best Practices. It is a bad term. It implies finality. Period. No room for improvement. This is it. No further. All trespassers beyond this point will be shot. Do not think.

Pure madness.

But, if you inject some context into best practices, you may get something useful. Let’s open that up a bit shall we.

Imagine you have a team of rookies. They have just graduated, know something about some programming languages and theory. How do you get them up and running? You tell and show them a good set of good practices that have been proven to be good. You give them a starting points. something along the lines of: Write the tests first. Automate your tests. Do not optimize prematurely. Ask questions. Ask more questions. And so forth. If they follow he advice you gave them they should not fail miserably. Let them learn from the experience of others.

But what if you have a bunch of craftsmen with several years of experience and that have been working together for the last 5+ years? Giving them something titled as Best Practices is effectively telling them to stop thinking. Imposing best practices will lead to trouble as these men or women will not follow your instructions. They will use whatever fits them best. Which will lead to a very interesting situation. Do they need to do what you or your company tells them? Avoid this scenario, at all costs. Pretty please?

Sometimes there might be someone in your company who tries to optimize your work without knowing the context or those nitty-gritty details. This may be even more disastrous than imposing practices from close proximity.

The road to hell is paved with good intentions.

Ignore these people (and if you have the guts, try to convince them that they are making the whole department/company worse, with 100% certainty).

There are no globally applicable best practices.

Everything depends on the context. We live and work within Complex Systems. Attempts to simplify such complexity into a container called best practices is not only impossible, but also futile and stupid. Things change, work evolves and best practices given from outside become stale very fast.

Best practices can be useful and give you a starting point when applied properly and within the correct context! Following a set of best practices may allow you to avoid some pitfalls that people before you have encountered, fell into and climbed up from. Best practices attached to a ShuHaRi-mindset allows you to learn from the masters.

Absolute beginners, novices, can benefit enormously by following the advice of experienced masters. But once you start learning and developing a skill of your own, you need to rely less and less on those practices. They become obsolete.  You can sidestep best practices and use those practices that fit your environment the best. When you know enough about your surroundings you can develop and improve the practices you use whenever and however you want. Best Practices are not a silver bullet. They will not save you nor improve your performance but they can help you to begin your journey towards craftsmanship.

What should you use then, if not best practices? I want to strongly suggest that you drop Best Practices for good and start using Good Practices instead. As a word, good has a positive echo, you can improve things that are good and you can even oppose a good practice if you can prove that there are better ways to do things. We all like things that are good and very often want to be better than good. Good practices give us the leeway to make things better.

There is always room for improvement.

ATDD and Legacy – what’s up?

A while back I had the idea of bringing the concept of Acceptance Test-Driven Development into our department, where we mostly maintain an existing, pretty large, mature and complex solution. The conclusion after my presentation and following discussions was that we already do it, at least partially (as I mentioned in this comment). With this post I want to elaborate where we currently stand.

Sometimes we implement the tests first, sometimes in parallel with the implementation but we never craft the tests during sprint planning. Main point is that we do not make any changes, fixes or new features without full tests covering the area of change. This is, in my opinion, the most important point. We do not accept code that is not covered by tests (unit and system tests!). For legacy systems this is an absolutely necessity. Otherwise you won’t survive. My presentation was deemed as a good one and it gave names and clarified concepts of certain things we already do. It is now much easier to discuss issues and improvements with a common vocabulary.

Very recently our team was chosen to implement something totally new. A greenfield project.

This brings totally new aspects to our development effort. We would have the possibility to do things right from the very beginning. With a long history of legacy systems this feels like a breath of fresh air. It is still quite unfathomable to me at least. We would be in a position to choose our testing framework (most likely the Robot Framework), and continuous integration and deployment policies. We would be able to define our working agreements and definitions of done so that we drive development with tests. I think we would be technically empowered.

On the other hand I don’t feel that we have been doing things in vain. The Legacy System will live on, it will need nurturing to stay in shape. It has a huge and lively customer base which generates a steady stream of feature requests and issues. I am convinced that our efforts of bringing its build, test and deployment systems to modern age will bear fruit.

Interesting times indeed!

(photo by angesnop)

Scrum – is there a role for tester?

Simple question, heard quite often though, has a simple answer, yes, there is a role for testers in Scrum.

In the following I try to clarify why.  And as a prerequisite a assume that we are talking about an intelligent tester, not just some simpleminded clerk who can execute ready-made scripts.

Why a tester is an asset?

1. Scrum team should be omnipotent. Erm, omnipotent when it comes to delivering functional software. You need testers to have a cross-functional team.
2. Testers have a different state of mind. They approach the problem from complete different angles than the developer. Tester is able to approach the System Under Test (SUT) from multiple perspectives, including but not limited to, system, functionality, user and exploitatory point of view.
3. Test automation. Yes, even though TDD is a big thing, and anyone can automate test,a capable tester is a huge asset for any Scrum team. Testers have usually invested quite much in their skills regarding test automation and they know how grab the low hanging fruit for any SUT and proceed from there.
4. Tech savvy testers provide valuable feedback about erroneous systems. I have experienced quite many problem cases which I could not have been able to correct had there not been a skilled test engineer to tell me how and where the system is broken.
5. A human equipped with a tester mind set, given the time needed and tools required to perform exploratory testing can save you from so many problems. Not to mention money saved.
6. Good testers will educate developers.
7. Good testers will become excellent developers.
8. Good testers can question the functionality in a different way compared to a developer.

Many of these traits are found in a tester. So, if you get a capable tester, hold onto her with every possible way you can.

What not to do with testers in your team

There is a catch too. You can easily expel a tester, make them useless and feel outsiders and ready to leave the company. They need the same care, nurturing and attitude as your ordinary developer. You should treat them equally.

And what is really important, this same goes with your developers without saying, do not tell them what to do.  Whether you are within the team or outside the team, do not place any pressure on your testers either as you wouldn’t place it upon your developers. But the most important thing is, don’t put any  external responsibilities, like feature acceptance gate responsibility upon them. Trust the whole team and only the team to give you the green flag.

Testers are after all a part of the team and have so much to give. Love your testers as you love your developers.

ATDD and Legacy systems

I’m going to give an introductory presentation about Acceptance Test Driven Development to our R&D unit next week. I’ve been harvesting the Internet for experience reports of applying ATDD to legacy systems to no avail. There are lot’s of basic presentations about it but nothing deeper and nothing regarding legacy code bases. So, with the absence of useful experience reports and proven strategies of applying ATDD in legacy systems we have to figure it out ourselves (well, of course we have to find own way! Blindly copying practices leads to failure).

The basics of ATDD should be easy to grasp but actually doing ATDD is much more harder than that. And given a huge legacy code base with only a roughly sufficient level of automated regression test suites even more so.

What I am after now is the sparkle, the aroused interest in the concept of driving full feature development with tests. We have a potential time slot coming up where we could turn one of our releases into a stable base and focus our efforts to test development beyond that point. But, I can’t do it by myself. I need others helping me. Should we get a good start on the concept of ATDD (we usually have quite excellent acceptance criteria for new features already) we have some work to do like choosing the tools and angles of approach.

But, first things first. I have to ignite the flame before we can cook anything. Wish me luck! :-)

Got: A New Pet Project

With thanks to Esko Luontola I now have a pet project. It’s called Dimdwarf. A direct descendant of RedDwarf but with some additional finery (the biggest difference being that managed references are invisible to the developer).

The project was written in Java (some helper scripts with Ruby) but all the new code is written in Scala. Thus, I got a perfect opportunity to hone my skills. Also, the project architecture contains almost all the things I have wanted to work with. It has Software Transactional Memory, it uses Guice for dependency injection, it is developed purely with TDD. No exceptions to that. And statics are forbidden! It is designed to be scalable, aimed for clusters and much more. See the project pages for more information.

Now, all I need is more time. Could someone add more hours to my day?

Wanted: A Pet Project

I have a positive problem. I need something to code with Scala at home. I’m kind of bored with code kata’s though practice is never bad for you. I just want to do something with a meaning, something more challenging. Maybe even something that someone could use and benefit from.

So, please suggest something! Existing open-source projects, new ideas, anything!

Done done with my holidays

Four weeks. Gone.

Darn, I could have stayed for longer but it is good to notice that I’m actually happy being back at work. Good stuff going on in here so no trouble of getting back to the rhythm. Well, It might take a day or too. Lot’s of things to catch up and remember.

During my holidays Scala 2.8.0 Final was released (I already updated mine) so there are plenty of new things to check with it.

I also made a new questionable record, my Windows host started up in 13 minutes. Couple of system updates were downloaded but that’s how long it took for my laptop to be usable. For comparison, my Kubuntu laptop took less than a minute.

Anyway, I’m going to start my professional life again, so expect more stuff in the near future.

Starting with Scala (IDE’s, tools etc.)

I’ve been learning Scala and during the process I have tried two different IDE setups, Eclipse and IntelliJ. They both can integrate Scala and provide syntax checking, test executions, code assistants and so forth.

I’ve been working with the Scala 2.8.0 release candidates so the environment has fluctuated a bit due to the changes between RC’s. Anyway, so far IntelliJ has been by far superior when it comes to project setup and stability. Scala IDE works pretty well but it hasn’t yet, in my opinion, reached the maturity of IntelliJ’s integration.

Writing unit tests with xUnit is simple, just drop in ScalaTest. Specs work nicely too, especially with jMock!

Scala Tools provide lots of useful stuff so grab what you need. I really loved Maven Scala Plugin since it made project creation a breeze.

The internet is full of good tutorials on Scala, one very useful entry point for Java programmers is Code Commits Scala for Java Refugees. Jonas Bonér has some good articles too. And let’s not forget the main Scala site itself. Documentation, Scala downloads, tutorials, resources, code examples, you name it.

Scala is good.

TDD and Internal Transformation

Many have gone through the agony of a Scrum transformation and noticed that revolution is hard. It requires a lot from the people involved but at the same time it is mostly adapting to new surroundings, to the new way of collaborating and making work visible.

Agile methods come with the implicit expectation that you start to implement at least some XP practices if you were not doing them before. From a developers perspective the most significant is TDD,  Test-Driven Development. It is a completely different way of building software compared to the ordinary implementation driven development where the developer thinks what this system has to do and starts to implement it. TDD starts from how is this system used and what is the expected outcome.

We admit in the very beginning that we know almost nothing about the system and its expected functionality and we try not to guess and implement for the future. Instead we drive our development from the user point of view – How is this system used? What roles do we have? You start writing out your most basic assumption of the system as a test. Focus on the immediate need which is to make the current test pass. Then we continue, test by test, digging out the behavior of the system. Tests are a just a catalyst to tease out the required functionality. Conveniently another widely used moniker for TDD is Test-Driven Design.

For many developers this represents such a major shift in approaching software development that the transformation is harder than the transformation to Scrum. Moving from waterfall to Scrum causes organizational pains and some individual pain due to the loss of familiarity and for the fear of the uncertainty. Breaking the status quo always causes discomfort. But moving from conventional (yes, I think that TDD is still the non-conventional development method) to Test-Driven development causes much more pain on individual level.

You have to make the change almost all by yourself. You may benefit from a coach presence and peer encouragement and gain momentum from them but in the end, it is yourself that has to change. You have to change the way you work in order to adapt TDD as an effective development method.Thus, I have come to the conclusion that

TDD fails and succeeds on individual level.

It is good if your organization tries to make TDD the norm, but at the same time it might not be possible. Some will work more efficiently the way they have been working so far and they can still develop good quality software. Don’t tell them how to do their job. Coercion always causes resistance and resistance makes the change so much harder that it might not be worth it. TDD must be introduced as another way of developing with the intent that this could improve your way of working. TDD can be beneficial to you. Again, leading by example might be the best way to introduce TDD to other developers. Thus, I have also come to the conclusion that

You can’t force TDD, it has to be consciously and actively adopted.