The Manifesto for Software Craftsmanship

I was reading Faculty of the Mind in Google Reader this morning and saw a link to the Manifesto for Software Craftsmanship. JB and I have been following some of the craftsmanship discussions, also nicely summarized on Faculty of the Mind. I read over the manifesto, agreed with it, and as I went to the bottom to sign it, I saw JB’s name. Looks like we’re both on board. How about you?

Advertisements

4 thoughts on “The Manifesto for Software Craftsmanship

  1. Won't your tests will decide what is simple enough? So, maybe (and this is my theory here) you don't have to. When your tests become cumbersome to write there is your clue that things aren't as simple as they could be. Maybe your system never get's big enough that those static methods don't start to hurt. Let the tests decide.

    Like

  2. But how do I know if I want a static method or a command pattern? Both are very simple, but which do I choose? If I start with a console app, do I start by writing code in the Main method, or do I start by creating methods in the Program class and call them in Main? Are they static? This is what I mean by "whose definition of simple."

    Like

  3. Again, the test is the decider. The Command pattern is easier to test in isolation, so that is what I would choose. With ICommand I can have mocks, fakes, whatever which would make testing easier. I am not sure how some class with static methods could be considered "simple". Naive, yes, but simple no. I don't find static classes/methods easy to test so I don't use them.

    Like

  4. But again, where is the definition of simple? Has TDD defined what "simple" is somewhere? I agree with your statement above, but what if someone else does not?

    Like

Comments are closed.