What Software Craftsmanship Means to Me

Throughout the recent debate catalyzed by Dan North, I have spent a significant amount of time thinking about what this profession is that I have chosen to pursue and what it means to me. During the debate Corey Haines and Dan had on Twitter today, my thoughts crystallized and I felt compelled to record them. I doubt that many will read this, but if nothing else, it will allow me to measure my progress when I come back and reread it later.

While I self identify as a Software Craftsman, like Corey, I find that I agree with Dan regarding the movement. Maybe I agree with Dan because I self identify as a craftsman. No one else calls me a craftsman. There was no exam, no council of masters, just me and a desire to write less crappy software. So what does it all mean? What is Software Craftsmanship?

Well, it means not writing crap code, obviously! But what is crap code? I have never in the last 10 years worked with a developer who set out to write crap code. Working at a Fortune 100 company with annual releases, a team that laughed at the one guy doing unit testing and code that could fill hundreds of Daily WTF posts, we were all doing the best we knew how and trying to regularly (every single year!) produce value for our customers. Were we Software Craftsmen? I guess so. I mean, nothing in the manifesto would contradict that assertion.

So what is Software Craftsmanship? More importantly, what isn't Software Craftsmanship? I think the Ri answer is "Software Craftsmanship is doing the right thing." That isn't likely the Shu or Ha answer. Who knows what they are? I guess it depends, right? ;-)

I'm in no position to define this movement, but I will share my thoughts anyway. What else are blogs for, right?
  • First and foremost, Software Craftsmanship requires constant self improvement through study and practice. This includes learning from the experience of others (books, blogs, discussion groups, Twitter, etc.) and willingly sharing your knowledge and experience with those in the community, especially your coworkers.

  • Software Craftsmanship favors Clean Code (as defined by Robert Martin): concise, expressive code with limited duplication, (many) single responsibility classes and clear abstractions. Learn about and apply the correct design principles and patterns for your solution.

  • Software Craftsmanship insists on testable code with high levels of code coverage. This is more important than some grand design with perfect abstractions and encapsulation. Let the tests guide your design.

  • Software Craftsmanship emphasizes maintenance and enhancement of existing systems rather than regularly attempting to recreate what a business has already paid to build. It can take years for a new system to repay the high initial development investment. If we let it fall into disrepair and demand a rewrite just as the company breaks even, we are not adding business value, we are destroying it.

  • Software Craftsmanship favors Domain Driven Design rather than Data Driven Design or RAD. RAD tools emphasize the creation phase at the expense of the maintenance phase of a system's life cycle. Data Driven Design produces systems that are bound to a database implementation, generally less expressive of the intentions of the solution and likely run into performance and scalability limitations (vendor promises not withstanding.)

  • Software Craftsmanship prefers simple over configurable, Little Design Up Front over Big Design Up Front, flexible code over extensive frameworks.
Well crap! That looks like it could have been part of a manifesto for Alt.NET! Is Software Craftsmanship repeating the past? What have we learned that makes this time different? I don't know. All I know is that I have been trying to regularly and consistently improve my skills, share what I know and inspire those around me to improve so we can stop producing quite so much crap. Any advice on how to do that better is certainly welcome.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more