Category Archives: Software Craft

Software Craft

Software Craft

People who influenced me

2 Comments

Over the course of creating the Ethics of Software Craftsmanship there was a statement included which tempted me to this blog entry for quite a while now. Here it is:

We can point to the people who influenced us and who we influenced.

At moment there are quite a bunch of craftspersons which influenced me. At the time I’m writing this I am working for three and a half years now in the Software business. Having finished university four years ago, I have gained a lot of experience from some great colleagues, which I never personally met, but which influenced me quite a lot. Today I decided to give you a list of these persons who might not know about their influence on me. I will divide the people into categories: Testing, Developing and Project Management. Personally I might also add Leadership in general, but due to my little experience in this field, I will leave this category out.

Continue reading People who influenced me →
Software Craft, Testing

Succeeding with project methodologies

Leave a comment

For my blog post Craftsmanship over Execution I had read about teams that were doing Agile, – i.e. Scrum – had practices – i.e. test-driven development. The point by that time concerned that another development team would hear “Oh, they succeeded with Scrum, let’s take Scrum and be successful, too!” There are several reasons why this is a bad idea and I decided to write about some of them.

Continue reading Succeeding with project methodologies →
Software Craft, Test Driven Development, Testing

XML Unit: assertEquals and fail

4 Comments

Some weeks ago I was challenged at work that led me to invent a unit test framework for xml files. After some basic first steps I decided to introduce the approach on my blog as well.

Motivation

Why did I need a unit test framework for xml files? Easy enough. Our product has an intense configuration consisting of several xml files for the customization part. On the current project I’m working on there is a configuration file which consists of about 18 Megabytes of customization in one xml file. Most of our other tests use to start up a full system (taking a bit more than 60 Megs of main-memory database in combination with oracle database persistence) and exercise the whole chain all through the system. Initially I tried to write a unit test using JUnit and JDom, but failed to have it executed in my IDE while the 18 Megs were trying to be loaded with an OutOfHeapSpace exception. Brian Marick had pointed out Assert { xpath } from Ruby some weeks ago and I started to consider this as an alternative. After realizing that nearly no one knows Ruby at my company and there would be drawbacks considering the way our company uses the Revision Control system, I forgot about these alternative.

Then I reminded myself on an approach using xsltproc and some stylesheets. Usability for our Continuous Integration framework was an issue, therefore I decided to produce an output similar to the JUnit XML reports, so these can be directly hard-wired. This blog entry will describe the first few functions that I built: assertEquals and fail. If there is a demand for follow-ups, I will try to come up with an approach similar to the Test and the Suite classes of JUnit. In the end a test runner will also be needed, which is currently handled by Makefile dependencies.

Continue reading XML Unit: assertEquals and fail →
Leadership, Software Craft

Misunderstood metrics

Leave a comment

My Miagi-Do school mentor Matt Heusser placed a blog entry on metrics today. Since I haven’t got the clear problem with metrics, I needed to contact him to fulfill The Rule of Three Interpretations. In our conversation I realized that he was referring to a concept, which I haven’t been experiencing in my three years of working as a software tester.

Generally spoken I was referring to metrics as using FindBugs, PMD or cover coverage tools on your software. For some time we have been using these for the framework that we grew on top of FIT for testing our software product. In combination with Continuous Integration you can see improvements and you can see where your project currently is. Is it in a good shape? Where might be holes? Which codepaths are not tested well enough? This feedback is essential for management to make the right decisions about the risks when delivering the product against your test results.

On the other side Matt refers to metrics on a different level. If your annual reviews and your salary gets decided upon management metrics, these are evil. The struggle I have is, that I am in the situation that I never worked in such a system where my personal performance and salary was based on some metric. Basically I can think of situations where this is evil. Here are a few:

  • A software architect getting paid by the number of architectural pages written.
  • A software developer getting paid by the number of lines of code.
  • A software developer getting paid by the number of software products finished.
  • A software tester getting paid by the number of tests executed/automated.
  • A software tester getting paid by the number of bugs found.

Speaking as a software tester, I would use a tool for generating the easy test cases that are easy to automated (I have been down this rabbit hole, I just realize, but wasn’t getting paid based on that) or use a spell-checker on our logfiles (I always wanted to do this, but didn’t because there are more severe problems than the correct spelling of some debug log messages). As a colleague uses to put it: When you measure something, you change the thing you’re measuring. Be careful what you measure, because it just might improve. When I understood these different meanings of metrics, I also got the problem.

Some time later I found the origin for the discussion. It is a recent statement from Tom DeMarco reflecting over 40 years of software engineering and measurements. Take the time to read. Here is the portion which I found most interestingly:

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

I believe that this will work. At least it will keep the team from being micro-managed and over-measured.

Software Craft

Mindful readings about Software Craftsmanship

Leave a comment

While looking through my personal backlog of blog entries, I found this one today. It cites a quotation from Uncle Bob Martin in one of his blog posts in April. Here is the quote:

I see software developers working together to create a discipline of craftsmanship, professionalism, and quality similar to the way that doctors, lawyers, architects, and many other professionals and artisans have done. I see a future where team velocities increase while development costs decrease because of the steadily increasing skill of the teams. I see a future where large software systems are engineered by relatively small teams of craftsmen, and are configured and customized by business people using DSLs tuned to their needs.

I see a future of Clean Code, Craftsmanship, Professionalism, and an overriding imperative for Code Quality.

The related article was named Crap Code Inevitable? Rumblings from ACCU. Today I remember, that I wanted to quote that article by that time to be a mindful reading. After having read over it again, this point is still pending.

First, the mentioning of doctors reminds myself of a visit at my doctor in May. I had a problem raising my arm after having exercised too much. After initially stating the problem, my doctor told me to stand up, raise my arm this way, rais my arm that way, raise my arm in another way, and then he had identified the problem. This was amazing when I realized that this way of analyzing a problem in the software is not as efficient. On the one hand it took him no more than 5 minutes to find the cause. On the other hand I realized his level of expertise at this. Clearly I doubt that there was a course back in university held, where my doctor learned this. Basically I consider that he knew how the muscles and fibers are connected with each other. But I clearly doubt that back in his university times there were practial courses where an injured patient with a problem in his arm like myself was asked and evaluated in front of the students. Likewise, even though I did not have a course on test-driven development, but I can take the conscious decision to apply it and communicate my intentions to my colleagues. For this to work I take my personal experiences with TDD and simply do it. Similarly this applies for Acceptance test-driven development. Every day anew I can take the decision to give the best I can in order to delight my colleagues and my customers. Personally I consider this to be an act of professionalism.

On the other hand the quote from above reminds me also about a problem I have just lately read about on Twitter from Brian Marick:

I detect a certain tendency for craftsmanship to become narcissistic, about the individual’s heroic journey toward mastery. People who think they’re on a hero’s journey tend to disregard the ordinary schmucks around them.

Heoric journeys are a problem. Mostly I refer here to an insight from Elisabeth Hendrickson and a work which I think was from Alistair Cockburn, but don’t know for sure anymore. The problem with our education system is that during school you’re the one that fights on your own during the exam courses. In the university it’s your work that gets graded. For PhDs this is even more dramatical (as I have been told, no personal experience with this, though). Then when you get into your first job, you are asked to do team work. But where should you have learned this? The whole value system that worked all of your life gets collapsed. So, what do you do about this? People being “inconsistent creatures of habit” create their walls around them making their work safe against the rants of others. But – and now comes my reply to Brian’s statement above – the Software Craftsmanship Manifesto states differently. Software Craftsmanship is about taking apprentices, teaching what you have learned, what has worked for you, build a community of professionals for valueable exchanges just like the teams from Obtiva and 8thLight has proven to us. This is our responsibility to do. This is professionalism in the sense of Software Craftsmanship and it’s among the things we value.

Software Craft, Testing

Testability vs. Wtf’s per minute

Leave a comment

Lately two postings on my feed reader popped up regarding testability. While reading through Michael Boltons Testability entry, I noticed that his list is a very good one regarding testability. The problem with testability from my perspective is the little attendance it seems to get. Over the last week I was inspecting some legacy code. Legacy is meant here in the sense that Michael Feather’s pointed it out in his book “Working effectively with Legacy Code”: Code without tests. Today I did a code review and was upset about the classes I had to inspect. After even five classes I was completely upset and gave up. In the design of the classes I saw large to huge methods, dealing with each other, moving around instances of classes, where no clear repsonsibility was assigned to, variables in places, where one wouldn’t look for them, etc. While I am currently reading through Clean Code from the ObjectMentors, this makes me really upset. Not only after even ten years of test-driven development there is a lack of understanding about this practice, also there is a lack of understanding about testability. What worth is a class, that talks to three hard-coded classes during construction time? How can one get this beast under test? Dependency Injection techniques, Design Principles and all the like were completely absent on these classes. Clearly, this code is not testable – at least to 80% regarding the code coverage analysis I ran after I was able to add some basic unittests, where I could. Code lacking testability often also lacks some other problems. This is where Michael Bolton, James Bach and Bret Pettichord will turn in heuristics and checklists, the refactoring world named these as Smells.

On the Google Testing blog was an entry regarding a common problem, I also ran into several times: Why are we embarrassed to admit that we don’t know how to write tests? Based on my experience project managers and developers think that testers know the answers for all the problems hiding in the software. We get asked, “Can you test this?”, “Until when are you going to be finished?” without a clear understanding of what “tested” means or any insight what we do most of the time. “Perfect Software – and other illusions about testing” is a book from Jerry Weinberg from last year, which I still need to read through in order to know if it’s the right book to spread at my company – but I think so. If a develoepr doesn’t know about the latest or oldest or most spread technology, it’s not a problem at all. If a tester does not know how to “test” this piece of code, it is. He’s blocking the project, making it impossible to deliver on schedule – escalation! What Misko points out in his blog entry is, that the real problem behind this is also testability:

Everyone is in search of some magic test framework, technology, the know-how, which will solve the testing woes. Well I have news for you: there is no such thing. The secret in tests is in writing testable code, not in knowing some magic on testing side. And it certainly is not in some company which will sell you some test automation framework. Let me make this super clear: The secret in testing is in writing testable-code! You need to go after your developers not your test-organization.

I’d like to print this out and hang it all over the place at work.

Journal, Software Craft

Take your time for improvement

1 Comment

Dave Hoover just raised an interesting point on personal improvement: Spend 50% of your working time on personal improvement. Basically I found myself in that blog post. Since about two years – since I have been asked for taking a leadership responsibility – I am constantly reading books in my spare time. Over the last year I started to read several mailing lists and blogs. I am thankful to have married a wife over the last year that is patient with me (I wonder how long she’ll stay that way).

What shruggs myself is the fact that Dave states it takes about five years to see the return on that investment. Five years seems to be a very long time. Reflecting over my life so far I must say, that I have spent more than five years already on improving personally. At the age of 15 I choose to lead a youth group at our local sports club. In my spare time I gave swimming lessons over the past thirteen years and also grew into the leader role at my sports club over the past 15 years. In the meantime – while making my diploma at the university – I was involved in three clubs at a time. Through all these I made great experiences in leadership and organisation. Over ten years I participated and helped to organise helpers for our season openings of our local open air bath. This was a great time and helped myself improve for my current job.

On the other hand I even worked for money at a local store during my university years. There I had to organise the order process for soft drinks, juice and later even alcoholic drinks. I had to organise according to market and seasonal demands and manage the surpluses. In the end there was a major rebuild of the store where I was highly engaged in. Over the years I had learned how to work together with my colleagues and contribute to critical work that is daily business at a local store.

All these experiences were a major part of the preparation for my current position. In the past I have been working with people, for people, sometimes even against people if I was convinced from the opposite. Taking some spare time now to support my journey towards mastery is just a little duty for me. Personally I just took out my calculator and tried to calculate the time that I might have left for my family with Dave’s proposal: One week has 168 hours, 6 hours per sleep each night, two hours for getting to work and back, two hours for eating, 40 hours of work, 20 hours for personal improvement leaves you with 42 hours of time you may spent with your family and for leisure activities like sports. This seems ok to me, but don’t blame me for my naive assessment of the situation. (My wife is working in retail sail and usually does not come home until 9pm due to this, so don’t try to project my situation onto you.) Take Dave’s point into account to at least try it out for a while. Personally I consider myself more of the former group of people in his statement:

I think it would be silly to try to force yourself to do it, you’d end up burning out. Really, I’m talking to two groups of people. To those who are already spending their spare time on becoming a better developer, I want you to know that your efforts will pay off, but understand that it will take between 5-10 years to see the most significant benefits of your efforts. To those who want to become a great developer but hold themselves back out of fear of failure or hard work, I hope to inspire you to give it a shot.

and Dave made me feel good about it.

Journal, Leadership, Software Craft

Grading, evaluation and good code applied to apprenticeships

Leave a comment

Today I had the opportunity to talk about some of the skills that I needed to learn while becoming a leader. The girlfriend of a brother-in-law is a teacher for primary school. Today I got into a discussion with her about grades in school. During the discussion I thought on where do teachers get to know how to grade a student. Since I had one in front of me, I took the opportunity to ask directly. She stated that there was no education or course during the time she spent on university on this. In Germany there are two years of traineeship for new teachers mandatory. She stated that during that time she learned just a few regarding the grading process. So most of the grading is done on intuition. Interestingly her description reminded myself of the very first few months of my group leader time, during which I had to do a performance review for one of my colleagues. No one had taught me up to that point how to do it, I just had one review so far for myself. There was no course back in university where I could have learned it. During my last ten to fifteen years I have been a swimming trainer and lead the swimming department at our local sports club for some time, but clearly this was the only opportunity where had experience from leading people – and these situations are less context-driven due to its nature of a teacher to a student. Even today it is still hard for me to reflect whether or not I take the proper intuition into account. (The bad news is that most of your colleagues will not take the courage to inform you of your bad decisions.)

Right before starting to write about this article, I noticed that there is a similar case for good versus bad code. What did I learn at the university about code? What had I learned about bad code? Good code? Most of the insights I have today come from my experiences at work. When I started about three years ago we had an undesigned test automation framework. There were lots of script functions without intent. Whenever I needed to put in something new, I had to go out look for the right place to do so. Additionally I was never fully aware if there already was a similar function that I should have been extended, decomposed, refactored to meet my new requirement. This was a mess. Over the past year I was able to get rid of this grown framework and introduce and grow a new one.

We focussed on good aspects of code there. Using test-driven development, refactoring and regular reflection while evolving our classes. This was a good practice and we even tried to avoid most of the deficiencies from our previous experiences. Over the last year we had some contributions from a team that did not follow your initial approach. The result is that there are currently two ways to do things. When inspecting the code I can now see the difference between good code I wrote, bad code I wrote and very bad code from that I permitted to be included into the code base. (There was an up in the findbugs remakrds, a down in the code coverage and an up in the crappyness trend after the commit operation. The bad code was visible.) The main problem is that my colleagues do not seem to bother, where the broken window rule comes in. There is much work left to do and I know that I will have to take the responsibility to clean up this mess.

The point that is striking for me is, that there is no education on these things that matter most during day-to-day work. You do not get taught the stuff to grade your students. You get able to do so by getting experiences, intuition and your own guts and hunches. Similarly there is no education for a good or a not so good worker. You have to trust yourself here. The same goes for the cleanliness of code. Despite the books I could mention (the one with just that name), there is no preparation in university for clean code. Similarly there is little to no education on good tests or not so good tests. From my perspective a major challenge for craftsmanship – be it software craftsmanship or even testing craftsmanship – is to teach these difference in an apprenticeship. This is our profession and our job to do in the years to come.