The Software Craftsman

Story Points Explained. Part 2: Size-based estimation

2009-07-16T12:18:00.005+03:00

In part 1, I explained (I hope) the need for complexity/size based estimations.
In this part I wish to explain how story points work, and why.

Story Points are an arbitrary value assigned to a story (feature, business task, etc.) based on its complexity relative to other stories. There is no direct correlation to time, nor should you attempt to make one. This means, you should never try to say "Hmm, in a fifteen day sprint we can do 45 SPs, therefore 3 SPs are equal to 1 day, so if I can do this in half a day, it's worth 1.5 SPs".

What should be going through your head is: Hmm, this story not very easy, nor is it difficult. It seems to be about as complex as that story which we estimated to be 3 SPs. So I'll call it 3 SPs as well.

For the release planning (i.e. when you prioritize stories for the next few sprints) this is good enough. It doesn't matter how much time something will actually take. The PO can decide whether to descope, and whether to implement earlier or later, merely based on relative complexity alone!

During the Sprint Planning session, each story is broken down (by the team, for the team) into development tasks, which are small enough to be able to estimate in time with sufficient accuracy. They add up the time, and keep taking tasks (stories) until they reach the amount of time they have to develop (number of work days in a sprint, minus pre-planned abscences, etc).

When they reach the limit, the team knows how many stories they can do in a sprint, and commit to that. At the end of the sprint, the sum of the story points of the stories they completed is their velocity (story points per sprint).

The sum of the unimplemented stories' story points remaining in the release backlog, divided by the velocity is the number of sprints before the requisite features will be done, and the time until they can be released.

This solves the PO's need to set the next version's release date (Look ma, no time!)!

Story Points Explained. Part 1: Useful Estimation

2009-07-16T11:23:00.005+03:00

The following is based on a real discussion. Names have been changed to protect both innocent and guilty.
Perry, the Product Owner: "How long will it take to implement the XYZ feature in the ABC project?"
Sam, the would-be Scrum Master: "Uh... I'll ask the team and get back to you".
Having flipped through a few books on Scrum, Sam heads off to the team room and asks the team to estimate.
Sam, returning with an answer: "A week, but remember this is just and estimate".
Perry: "Sure, sure. Great. Thank you".

Sam, being in tune with the Force, feels a cold wind on the back of his neck.

End of the iteration comes, and the feature took ten days to implement.
Perry: "You said it would take 5 days. It took 10! What gives?"
Sam: "Hey, I told you, it's just an estimate!"
Perry: "Estimate, okay. I expected up to half again, and padded accordingly, and billed the customer. But you took double! Your estimates are worthless!"

What's the trouble here? Was Perry wrong to use the estimate? Was Sam wrong to give it?
I think not. I think the problem lies in their failure to communicate needs and expectations.
Here's a stab at how the conversation should have gone:

Perry: "How long will it take to implement the XYZ feature in the ABC project?"
Sam: "Why do you need to know? Let's take care of this at the Sprint planning session".
Perry: "Well, I've got a customer who wants a patch with that feature. I need to know what to bill him".
Sam: "I see. And do you have to know the amount of time it will take, in advance?"
Perry: "Duh! How else will I bill him?"
Sam: "Hmm... Do you bill him by the hour? days?"
Perry: "No, but a small feature will cost differently than a large one. And a customer needs to know what he's paying for".
Sam, smiling, as he already has the answer: "So, you're saying that you're charging on a scale, right?"
Perry: "Right."
Sam: "Well then, why not charge based on the size of the feature?"
Perry: "Aren't you listening? That's what I'm doing!"
Sam, grinning broadly: "Then why didn't you ask me what size the story is, instead?"
Perry: "Because you already told me before the last Release Planning session, that it is 10 story points..."
Realization dawns on Perry's face.
Sam raises an eyebrow.
Perry grins sheepishly, and slaps his forehead. He turns away shaking his head, and heads towards the place where all POs go...
Sam congratulates himself and rides off into the sunset...

The most important thing to understand about estimation, is the reason for it!
In my experience, there are two reasons to make an estimation:

To bill a customer, in a time-based (cost) project.
To know when the next version's release date will be. Gotta keep them bosses happy.
Prioritize features - often. we'll want to release something small earlier.

while these needs seem to indicate that we need a time based solution, it is actually not the case. Time is a real-world, quantifiable and tangible measurement. It conveys a sense of accuracy that may or may not exist. In software development, there is a long list of factors that increase the variability, and thus the accuracy of a time-based estimate.
Here's a short list:

Understanding the requirements - often the needs are unclear, volatile or both.
Understanding the technology - frameworks, especially for enterprise applications are too vast and complex for anyone to truly understand all of it. Thus what one needs for a project, he may often learn for the first time while on the job.
Who does the job - in all but the simplest tasks, software development is done by a team. A team is made of heterogeneous members, each with different skills, and different knowledge. What may take one person 1 day could take another 2 days, and vice-versa.
etc.

In short, while in "the real world" time is a measurable factor, in practice, it is the product of job-complexity and worker-skill (speed) - two variables.

The simplest way to increase our accuracy is to eliminate one of the variables: skill. What we're left with is a need for a complexity-based estimation method
Enter the story-points.

Continued in the next part.

Scrum, Done, and the Shared Specialist

2009-05-12T10:09:00.000+03:00

Scrum suggests that we form cross-functional, self contained teams. The reason for this, is so that when a team gets assigned a User Story, or feature, the team can, on their own, reach "Done", without being stalled due to dependency on external factors (e.g. the GUI team) not finishing their tasks on time.

As such, if the DoD includes (for example) development, testing, documenting and integrating the feature, the team should have members with the required capabilities.

The reality, unfortunately, is that some specialized skills are often required (DBA, integrator, technical writer), and there is no justification (or money) to have one such specialist in each time. Likewise, the tasks are complex enough that people without these specialties are not qualified to do the work (i.e. only THE technical writer has a sufficient level of English, or better, some other language to write the documentation, or the R&D department has decided that only certified DBAs can touch the database).

With two opposing requirements - self-contained, cross-functional teams, and specialization, how can we truly enable the team to be responsible for a feature getting "Done"?

Unit Tests are not Enough!

2009-05-04T15:09:00.002+03:00

TDD proponents often claim that with 100% coverage proves that the software works as expected. Whether they actually believe this to be true, or whether they are trying to convince management or developers to jump on to the TDD train, they are headed (and leading) the team to a fall.

The simple reason, is that a test proves that the software works as the developer intend it to. How does this guarantee that the software does what the customer wanted it to do?

It doesn't.

While high coverage is important in order to ensure that the software does what the developer intended, and enables the developer to know how the software works (with the unit test being used as an example of the API), we need Customer Acceptance Tests, preferably automated tests, in order to verify that the customer's intent was captured.

In short, Unit tests and Customer tests are both necessary to ensure quality, as they both validate the software in different, complementing ways.

When to Mock, and When to Stub

2009-04-30T18:41:00.002+03:00

One thing I noticed, ever since I got the hang of mocking, is that like anything, there is such a thing as too much of a good thing!
I started writing out my code decoratively, using unit tests to define the behavior expected of the production code. Next, I wrote the production code that would fulfill these expectations. And the test would go 'green'. All was good.
Or so I thought.
As the system grew, and I found myself refactoring code that was under the test harness, I spent more and more time fixing tests that failed because the production code ceased to behave as expected!
Oddly enough, the assertions, and thus the actual, final results of the tests were unaffected.

I realized that there was a pattern here. I was testing behavior, when I really cared about state.

My conclusion was this: If I'm testing a unit within the system, i.e. depending entirely on more code of my own (or on nothing at all), I should test state (i.e. make assertions about the results).
Otherwise, if I can't test the result of the code (i.e. a void method), or I'm at the system boundary (i.e. depending on code that is not part of my system), then - and only then - should I mock that dependency, and test for behavior (i.e. make sure that a dependency gets called).

But what if I have a dependency that I want to fake it's result? Use a stub. Your favorite mocking framework has mock-like constructs, that do not raise exceptions if the expectation fails. Those are called Stubs. Otherwise, use simple inheritance to fake a class and spoon-feed the return values.

There. That makes sense.

Now go, loosen up that strict behavior management.
It's okay. I can wait.

Why is Agile such a Hard Sell?

2009-03-15T18:43:00.007+02:00

Did you ever try to sell Agile development to the upper management? How often did you encounter a response similar to "That's not how it works in the real world"? I came across this in numerous conversations, with members of every level of the organization, from programmers, to team leaders, to PMs, to marketing to CEOs. It seems to me that the entire gripe everybody has with Agile is centered on the Iron Triangle: The customer wants everything he asked for, exactly when he needs it, and the budget is exactly what he's willing to pay.

Every single agile development methodology I've come across, states in no uncertain terms that they (they being the customer, management, marketing, PMs) simply can't have it. The agile proponents say things like "it will be ready when it's ready" (very bad for business), or "We'll deliver what we can by the deadline" (not very good for business, either).

So, for the non-agilists out there, it's a no-brainer. Up until those crazy extremos and scrum-masters (what the hell is that?!?) came along, we could tell the developers how long they had in order to develop the system we require, and come hell or high water they would burn out the candle on both ends, working nights and weekends to make the deadline. Kindly take your "Agile" and stick it where the sun don't shine!

What management conveniently ignores, is that most of these commitments are never met. And if the software is out the door by the deadline, the quality sucks. Why is that? Quite simply because there are no free lunches. Resources * Schedule = Scope. In otherwords, there's no breaking the triangle. Management is simply used to a methodology hinged on wishes. The way I see it, Agile is the proverbial messenger being shot for exposing the truth of it.
PMs often prefer to get forgiveness, or figure out how to shift the blame, for missing the deadline, than to get the permission to do so. I wonder how many clients would agree, if the software shop asks them: "Is it okay with you if we lie about our abililty to deliver all of this by the deadline, with what you're paying"?

What Agile methodologies such as XP and Scrum truely does for business, what really needs to be emphasized in an elevator pitch, is that they offer a solution to the problem agile exposes. By focusing on delivering, in high quality, what the customer needs most, by enabling changes further down the line, deadlines can always be met, by delaying the release of low priority features.

What do you think? Are there other reasons that managers dislike Agile?

The Power to Control the World, is in Which Finger?

2008-12-18T16:33:00.002+02:00

The title is quoted from the movie "Willow" (1988). The high wizard made his annual appearance at the village to choose an apprentice, held out his hand, and asked the question. Each contestant picked a finger. They all failed. As it turns out, the correct answer was the contestant's own finger. In choosing the wizard's finger, the would-be apprentice showed no faith in himself.

I was reminded of this, 20 years later, when I came across a company with a notion that to be agile is to practice TDD, or iterative development. Or any other practice.

The way I see it, TDD, iterative development, pair programming – they are all fingers. The correct answer is that agility is in you. It is a state of mind, an orientation.

To truly be agile is to decide to be agile. It is to follow the spirit of the manifesto, to accept the concept of XP or Scrum. The rest are practices. Details. If you are Agile, then your practices are agile by proxy.

So tell me: The Power to Be Agile, is in Which Practice?

The Hardest Thing I’ve Ever Done

2008-12-18T15:47:00.002+02:00

The hardest thing I've ever done in my career as a software architect is to choose the simplest thing that works. When I first came across the concept in a book about XP (Extreme Programming), I immediately fell in love with the agile concepts of pair-programming, and test driven development. I also became very enthusiastic about automating the build process, the metrics used to "keep score" of how the project is coming along.

It was the simple design that caught me by surprise. I'm used to writing smart designs. I'm used to writing code that is extensible at certain points. Designs that are elegant. Oh and design patterns. Lots of design patterns. I mean, you know what it's like to show everybody the class diagram, and show how you can later add another behavior without having to change the existing code. Oh, the pride. Of course, I have to make my designs like that, or else I'll have trouble justifying my salary as chief architect, right?

There's just this one little snag: Change. The customer wants something that requires us to rethink a constant into a variable. Even more often, that strategy pattern I worked so hard to put into place (even though in the meantime there's only one concrete behavior in the system, we expected more to come later) becomes useless, as the additional behaviors we were sure would be designed in the next iteration are never called for.

The cost of maintaining that extensibility point may be high, or low. It is, however, invariably cheaper not to maintain it. If you have your safety net of unit and functional tests (you are writing automated tests, aren't you?), refactoring a fixed behavior into an extensible one should be fairly easy. Even if it is more expensive to add an extensibility point in the future, than it is to do it from the get-go, it will be cheaper than to maintain all of the ones you don't need.

Test-protected refactoring is cheaper than maintaining pointlessly complex code.

It really is as simple as that.

P.S. As Chief Architect, I now find pride in the elegance of a code base that is exactly as complex as it needs to be, and not any more than that.

How to Write Great Software Design Specifications

2008-10-17T22:47:00.004+02:00

When I began my journey as a programmer, I neglected design documents. I couldn't stand writing those long books that described what "the system should do". I just wanted to get there. At most, I'd do a sketch of what the UI should look like, and then I'd start coding. I trusted my memory and my ability to juggle a myriad of requirements in my mind. I can honestly say that I'm really good at it. I can run algorithms, complex ones in my head, and see what is supposed to happen.

Of course, no development manager could accept that. QA needs to know what the software should do, so they can write tests. Collaboration with other developers necessitates design documentation as well. And of course some customers require them as delivery milestones. Finally, as I've learned time and again since those days coding on a wing and a prayer, more than a decade and a half ago, designed software is easier to maintain than software without a design.

So we need a design. How much? What kind? When? Here's what I do:

First, I filter by the three acronyms: YAGNI (you aren't gonna need it), TAGRI (they aren't gonna read it) and DRY (don't repeat yourself). What this basically means is that I won't put into design specs anything that will not be of any use to the developers, the customer or the testers. Likewise, it means that my designs can't be too detailed: they should not repeat what the code will say. This last statement hides the simple-yet-important fact that code should document itself.
Second, I'd rather be somewhat vague in my design. I don't want something so detailed that it won't survive the first conflict with reality. I hate spending hours (or even days) on a design that will change within an hour from the moment somebody sits to read the code. It's like the coding-to-abstract principle. Think of the design as the interface and the code as the implementation.
I like diagrams. I prefer them to words. To me, they allow me to see more of the system at once. UML is great. The most important diagrams to have in a design document are:

Use Case Diagrams: While they don't tell enough of a story by themselves, I find them to be invaluable props for design reviews, and their simple and intuitive language makes them ideal for presenting to business people: Management, customers, etc. For developers, they show encapsulation, top level components, break features into tasks, and show what needs to be mocked.
State Diagrams: Where applicable, these are invaluable to translate business requirements into code.
Component Diagrams: A component is a set of classes that work together to achieve one goal: It may be one class, or many, and may span packages (dlls, assemblies). Showing how they interact with each other is the lowest level of abstraction that should be part of a design document.

Anything else, any artifact of a lower level than a component (sequence diagrams, class diagrams) should be done by the developer, when coding, to help him think through the task. These are generally either throwaways, drawn on whiteboards, or slips of paper, or kept as part of the documentation of what was done (rather than what will be done).
In .NET in the visual studio (2005 and up), the class diagram is not a document but rather a graphical rendering of the actual class. It is full synchronized with the class libraries themselves. As such, I like the class diagrams to be maintained in order to help with the code review.

In short, keep it lean, make sure it is specific enough so that it is of benefit to the developer, vague enough so that it isn't rendered obsolete by the first few lines of code, and make the highest levels transparent enough so that non-technical people can understand it.

The Good, the Bad, and the Ugly (Documentation)

2008-10-13T09:43:00.008+02:00

Documenting, once a constant in the world of software development has become, with the rising of Agile Development, a somewhat controversial subject. As late as the mid 90's it was a well known fact that you have to document. The more documentation, the better. Management expects it to be there for posterity! Documentation is all that enabled a corporation to retain its intellectual property once the developer of a software project left the company. The larger the company, the more regimented the documentation was to be. There'd be page-long paragraphs at the beginning of each file, describing who wrote what, copyright, purposes, and examples and so on. Then you'd have a few lines above every method, procedure or function, describing its purpose, and usage. Then each block of code (roughly 5-20 lines) would be documented as well.
And that is without mentioning the Book. The book is a thick manual describing the system, "ideally" capable of telling the would-be programmer everything he needs to know about how to develop.

Of course, I haven't, in my 15 years of development, occasionally modifying code that was up to a decade old when I reached it, seen documentation worth reading. It was consistently outdated, in variable degrees of staleness. What was there was often self evident, once I understood the codebase. Needless to say, it was of limited use to me.
Reflecting back on the matter, I wonder if this uselessness could be the reason for the neglect by myself and others before me.

Then came Agile (bring out the fanfare). A new world order was emerging into existence. YAGNI and TAGRI came marching in, bringing down the hegemony of farsighted API and vast documentation (respectively). A new concept became publicly known: quality of documentation. What should you document?

The hardest part of writing this post was to define the difference between bad documentation and ugly documentation. In the end, I came up with it. So, without further ado, here they are:

The Bad

Bad documentation is a comment, that is, quite simply, not worth reading. Reading bad documentation is at best a waste of time, telling you nothing worth knowing, or something that is self evident. At worst, bad documentation is misleading, and reading it will lead to false assumptions and mistakes. Here are a few examples of bad documentation:

Not worth knowing:

// I can't remember what this function does
bool DoSomeObscureOperation(object a, object b) { ...}

You may laugh, but I've seen this. Many times. This kind of documentation earned many a developer in my team a spanking. Well, I didn't actually give one, but I really wanted to. If you aren't explaining the code, don't do it there. Don't write about not remembering something - ask someone.

Note however, that many IDEs allow for placing to-dos and tasks in the code as comments. These are useful place holders to let a developer record what must be done, but couldn't for some reason.

Self evident:
// Returns the list of the user's favorite titles
List<Title> GetUserFavorites(User user) { ...}

No, Really?!? I swear, I saw this. I admit, as a developer, I once was required to write such comments. I never understood why, and I discourage such bloat in my codebase.

Misleading:
// Returns the list of the user's favorite titles
List<Actor> GetUserFavorites(User user) { ...}

Obviously, either this comment is the victim of a Copy-Paste gone badly, or the new operation was added between the comment and the original code. This might seem contrived, but see what happens when you get run time errors, because you used the wrong operation, based on the code, and then typecast the result to a different kind of collection.

Bad documentation can also be more insidious. It can disguise itself as good documentation, describing bad code. If you have bad code, don't explain it - fix it! It should be easy after all. You've got your Unit Tests in place, right?

The Ugly

Ugly documentation stacks with bad documentation (i.e. it makes bad documentation worse). It can also disguise good documentation as bad. Ugly documentation is simply hard to look at. It can be full of spelling mistakes, its indentation can be off, capitalized, all in one case, etc. If it offends your eye, and you'd rather ignore it, it's ugly. Perhaps a spell checker wouldn't go amiss here.

The Good

Good documentation is easy to spot, easy to describe, and a real challenge to write. It is everything that bad and ugly documentation isn't: It's well written, it tells you something you didn't know, it's synchronized with the code, it reduces effort and it saves you from making mistakes. The challenge, in writing good code, is knowing when to comment, and when to refactor. Good code is self documenting. The best documentation is the code itself: It never lies, and it isn't self evident (in as much as without the code, there would be nothing).

This is what I ask my team to document:

For each class and interface, describe shortly what its (single) responsibility is. This helps other developers to decide where they should add that new operation they need, as well as what they need to use.
For service APIs (only), document the service contract as you would a class or an interface. Additionally document each operation - as long as you aren't translating the operation signature into English.
Avoid in-method comments. Make the code self evident. Use good variable and method names.
As a last resort, if you really can't refactor a hard-to-understand operation, explain the purpose of the algorithm (not the algorithm itself). But for your team's sake, make sure it is the last resort. Code changes, so you'd be better served documenting the abstract and using member-names for documentation.

There. That's it. Now you know. And finally, a piece of parting advice:

If you're gonna code, code. Don't doc!

Yes, I was rather proud of that one.

Value Driven Development

2008-10-12T21:37:00.002+02:00

This might be the next big thing, the new buzz word of the agile world.

In Test Driven Development (acronymed to TDD), the goal is to test everything. In Domain Driven Development (yup - DDD), we strive to make an excellent Domain Model - that's our goal. In eXtreme Programming, a.k.a. XP, the idea is to program without having to design anything, and in Scrum, the goal is to huddle together and come up with a short Gantt chart that states what we promise to deliver in about 3 weeks. Ideally, we'll have several iterations planned in advance, so that we can have a long-term view of things.

The problem, as management, will be quick to tell you, is that sometimes we have to forsake these noble goals, and focus on delivering value to the customer. So here's my idea: Let's propose a new agile methodology, Value Driven Development, where we use agile process to constantly create value for our customers? That, as we know, is always our goal, right? The business people will love this.

For those of you, who did not stare in shock and disbelief at the first paragraph, let me make something clear: Everything I wrote there was wrong! Everything I wrote is an unfortunately common misconception about the respective agile methodologies. The truth is that these so-called "goals" are the means to the end. What end? Value, of course. But read on, please. Explanations to come...

The question is why are these misconceptions popular? To answer this, I'd like to describe a rather common scenario I came across:

A development team is in trouble. The code base is horrendous, the schedules are ignored. Feature requests creep uncontrollably, and the bugs increase in polynomial proportion to the number of changes made to the system.
Someone, usually a veteran developer, perhaps a team leader, but often not, stumbles upon a book on agile development. Perhaps a blog.
The developer reads the book, cover to cover, constantly smacking his or her head, exclaiming things like "OMG! That is exactly what happens to us! This is exactly what we need!!!"
The developer runs to his manager - all the way up to the CTO, telling them how this or that agile development process will save their bacon.
A few days later, the idealistic developer makes his presentation to management. Describing the artifacts of DDD, or the Planning Poker session and Daily Scrum. Or perhaps touting the benefits of pair-programming ("We put two programmers together, and we'll have bug-free code, because the second programmer sees things that the first misses").
Management quickly assesses these things as Nice-To-Have (at best), and responds with something like: "I can't authorize putting twice the resources on a single task! It'll take you twice the time to write the code, in man-days!" or "This card game is silly. We won't do it." and of course, the inevitable "I don't care how you write your designs - write whatever Domain Model you need, just deliver bug-free and on time."
The room is empty. The developer picks up his laptop, and wonders how everything went wrong. "How come I'm the only one that understands this?"

The answer is simple. The presentation was simple, straight-forward, technical. It did not present the real value to the customer. The presentation was geared towards the people who will implement the methodology. The business people need the abstract. And they need to know the "return value" (i.e. what the actual, quantifiable value of a certain methodology is). The decision makers need to understand the interdependencies between a methodology's processes.

This is much like the Dependency Inversion Principle. To quote Robert C. Martin, "High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions". In other words, don't confuse them with details. Explain the idea, the essence. And make sure the process implements that essence.

They need to understand that XP promises robust code by combining group responsibility with rigid standards of coding. They need to know that this is done at no expense to delivery schedules, because the small increase to the initial coding phase will pay off in greatly reduced time to debug and change the same code.

They need to know that Scrum offers a highly visible management process, and increases the values of effort estimates by early exposure of risks, and a commitment to deliver the greatest value early on, and allow the customer to change his demands to adapt to the rest of the world.
There are more values in each methodology than I can put into a blog post, but the important thing to understand, and even more importantly, pass on: Is that every agile methodology is a Value Driven Development methodology.

So next time you try to sell Agile to management, focus above all else, on the actual value to the customer, to the business. Use graphs, quote from white papers. Leave the specifics for the implementers. Or, if the details are requested, make sure to highlight interdependencies, so as to discourage uninformed picking of artifacts from various methodologies in what seems to be an effort to reduce costs and increase value even more - that is the uncharted road to agile hell. But that is for another post.

All-Encompasing Methodologies

2008-10-11T20:23:00.005+02:00

A theory tries to explain a phenomenon. It isn't offered as solid proof. That's what laws are for (as in laws of physics, of course). The more it explains, the better the theory. The best theories are unified, all encompassing theories.

For methodologies, I believe that a similar statement can be made: The more ways it can be applied, the better the methodology. Consequentially, I believe that applicability is a good heuristic for finding good methodologies.

I've taken a few courses in good parenting, and talked with couple-counselors as well (don't worry, my wife and I are doing fine - I believe in taking preventive measures whenever I can). They all seem to emphasize that the key for a good relationship is communication: Communicate your desires, communicate what you are willing to do, what you aren't, what you can or cannot do. Now take a look at Agile software development. The Agile Manifesto states in it's fourth principle that Business people and developers must work together daily throughout the project. Further, in the sixth principle, it is stated that The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Another example of cross-discipline application of the agile methodology is in martial arts. In an advanced class I took recently, the Master taught us two things, which are key to the art. First is that agility is the basis for all. Most techniques will fail, or at the least be less powerful (i.e. less value) if the practitioner isn't agile and flexible enough. The second is that many (in fact, I believe most) stances are designed so that the practitioner commits to a move as late as possible. This is necessary because the world doesn't stand still while you make your move. Your opponent is also doing something at the time. Agile Methodology calls this embracing change.

From parenting to marriage counseling to martial arts to software development: Communication, Collaboration, Agility and Embracing Change. These are the keys to producing value.

And the diverse applicability of these principles are tantamount to proof of their truth.

Originality

2008-10-09T22:07:00.006+02:00

I've never claimed to have an original thought before.

George Carlin, R.I.P. once said that he'd like something extremely offensive and painful to be done to him, with a red hot poker. No, I'm not going to repeat it here. This is not that kind of blog. The thing is, he said it, just so he could claim to be the first person in the world to have ever said it.

It used to be my life-long goal to invent something. The next killer-app, the holy grail of software developers, to come up with that thing that nobody ever thought of before, and make about 100 million dollars, give or take a few nickels. Of course, I'd still like to make that kind of money, but this morning something dawned on me. I knew it before, I've learned it in the university, and empirical data supports it, but it just never registered with me before.

You don't have to be original to make a killing. Just be better than the rest. So the next time you have a brilliant idea for a product or service, and when you google it and find about a million hits to the term, and a product just like your idea within the first five hits - twice - don't pull the plug on it. see if you can come up with a feature you think is really missing. See if you can make it better, cheaper, faster.

I promise I will, next time.

And one more thing, regarding originality:
I called myself The Software Craftsman. Honestly, I'm just A software craftsman. I've seen the term coined by others before me (actually, I googled the term today for the first time, and realized it's been there before me).

What I can say, is that I thought of the term on my own, out of my own experiences.

So if anybody believes that I am a plagiarist, please let me assure you all: I'm not. I merely reached the same ideas and conclusions as others before me.

Hello...

2008-10-08T21:49:00.006+02:00

Hello. My name is Assaf, and I'm a Software Craftsman.

To be honest, I'm half expecting to hear a loud chorus of "we love you, Assaf..." Okay, not really, but you have to admit it does seem appropriate.

What's a software craftsman? According to Miriam Webster, a craftsman is 1. A worker who practices a trade or handicraft, and 2. One who creates or performs with skill or dexterity.

It is the second definition that I find to be of interest. One who creates or performs with skill or dexterity. Now, don't get the wrong idea here. I'm not trying for a nice pat on the back (though I'd never say no to one). To me, this definition implies that I use skill and dexterity in order to create. It is not enough to merely create or perform. The craftsman must bring his skill to the job. Otherwise, he's just working, not crafting.

This, to me is the essence of what a software developer should be. One must care enough about the code he writes, that he won't be satisfied with merely writing enough code to (hopefully) cover the requirements of the task. The craftsman in me strives to be skillful. Strives for quality.

Sometimes, though, I wonder - am I alone? Am I highly motivated or just plain "high"? Am I a perfectionist or a deluded dreamer?

How about you? Are you a craftsman, too? Tell me.