Posts Tagged ‘code’

Software development as a craft

December 10th, 2008
4
Digg me

Most people don’t understand what software development really is. They think of computers, automation, and repetitive dull work. Maybe you’ve heard the phrase “even monkey could do it”. Hell, I’ve used that one myself describing my work. Even many of us who are in the industry, don’t seem to grasp the true nature of it. Not so long ago, I didn’t have a clue myself, but recently I’ve started to look things differently. I’m still in the dark but I’ve seen a glimpse of light. Does this sound like a cliché yet? ;)

As a software developer, it’s all about your own attitude, self-respect even. More precisely, it’s about being professional. Sure, you can be the code monkey and not care about what you do, how you do it or in what environment you do it. This is how most people think, and this is exactly the reason why software developer as profession is not appreciated in a way, as it should be. If you think about it, this applies exactly the same in almost any profession. What makes software development special is that it’s not merely about engineering. It’s more than that. It’s an art. I stumbled across this post by David Christiansen, which is about how professionals perceive software development, or how it should be perceived. By now, you should have a clue what I think about it, at least from the topic of this post…

I’ve come to think software development as a craft. This is not something that I’ve made up myself, obviously, but it something that I’ve really started to relate to. There are many great blogs and articles about the subject, and here is one of them: http://blog.8thlight.com/articles/2008/9/22/definition-of-software-craftsman. There the author Micah gives a good definition of software craftsman and software development as a craft. I’m still in the process of feeling out about the whole Apprentice – Journeyman – Master thing, but I’m starting to like it. Anyway, what Micah says is: “A craftsman takes pride in his work an strives to do the best job he can. He believes that writing good software requires skill and careful attention. That software is not something that can be manufactured nor can it be delivered faster by merely adding more bodies.” I’m a craftsman. I’m might be just in the beginning of my path, an apprentice, but this is something I really believe in.

There is a very entertaining and good series of writings about software craftsmanship by Robert C. Martin, or Uncle Bob if you will. Go to http://objectmentor.com/resources/publishedArticles.html and select Craftsman from published articles topic list. It’s a very long story but it’s worth it. That series is actually the first contact for me about software craftsmanship. It also introduces some good sw-practices such as pair programming and TDD. 

I come from a school where software development is first and last defined as a business. I wasn’t supposed to get involved in the actual development and coding. But I did, and it took me a long time to change my attitude towards it. I always liked coding but I never pursued it as a career. Now, as I said before, my whole world is changing. I have always valued humanistic sciences and arts & crafts (I still do!). Now I’m starting to see that same value in software development, which I used to see only from the business point of view. I have to admit, this is a change I welcome with open arms. Even though I’m not a senior developer, not very experienced and not very skillful, I’m still able to notice that many developers around me don’t give a crap. They don’t value the work they do and they don’t value themselves. I want to do something to change that.

One last note, when I talk about software development, I don’t mean just coding, but everything from project management to testing. It’s all good. :)

Test-Driven Development

September 5th, 2008
2
Digg me

Writing tests is pain because your code is not written to be testable. Why not try something called Test-Driven Developement?

Example: You need software which involves dogs… :) So you probably need a class called Dog. Instead of writing the class first, try to imagine what you would like the class to do. Don’t just imagine it; write a test which demonstrates how you want your dog to act.

class DogTest(unittest.TestCase):
    def testBark(self):
        dog = Dog()
        self.assertEqual('wuh', dog.bark())

You run the test and see it fail. Obviously, since there is no Dog yet! What you have done is that you’ve made a design decision, that you wan’t the dog object to bark by calling its bark method. Now you only need to implement it, and it’s a breeze since you already have the test to back it up:

class Dog():
    def bark(self):
        return 'wuh'

Congrats.. You’re test driving! Simple, isn’t it?

For more information try google or some of these links:
http://www.agiledata.org/essays/tdd.html
http://blog.objectmentor.com/articles/2007/07/17/testing-will-challenge-your-conventions
http://tech.groups.yahoo.com/group/testdrivendevelopment/
http://www.testdriven.com