How’s your agile process working for you?

Are you practicing an agile process in your team? Do you still find your team working through the night? Do you still find your software to be rigid, fragile and immobile? Do you still find changes of requirements to be nightmares to the developers? How do you suppose those situations are possible with an Agile process?

Unfortunately, this is the situation in almost all Agile practicing and Agile preaching companies we have around in Sri Lanka. I’ve crossed my paths with quite a few developers from these companies and they all have the same story to tell; agile for them, is the same old cycle, without the documentation and without a designing phase - which makes their development life worse. Non-technical project managers are still around, being called by other names, and to add to the misery, now the customers bring the pressure directly to the developer - because it’s “Agile”.

Is Agile a bad idea? What’s going wrong? Why can’t we make it work? Have you seen the list of names in the Agile manifesto at http://agilemanifesto.org/? Do you think those are the kind of people who would invest on a failing process? Besides, they’ve been practicing and teaching it for over a decade now. So if there’s anything wrong with Agile, it’s more likely in the way we practice it.

Management elements such as deadlines, budgets and sucking up to customers’ aside, we developers too need to change some fundamental ideologies towards development in order to make Agile, well Agile. It is not to say that the operational model doesn’t matter, indeed, that’s what makes Agile possible. Someone should be available to the team to represent the customer, acceptance tests should be automated and made available to the developers when feature requests / changes are made; team should be responding to changes than follow a plan; team should be able focus on getting a working product out instead of documenting etc. etc. which all agile gurus will tell you; but the part they don’t speak about; the part the folks came up with agile manifesto took for granted; the part that is responsible for more than half the agile failures in Sri Lanka is with the developers.

One misconception most developers in Sri Lanka have about Agile development is, it is coding without design or documentation. The other misconception is to think getting software to “work” means getting the functionality out one way or another. The Agile philosophy has very different interpretations for these and is defined with the implied expectation of strong object oriented concepts and design principles of the developers.

By the term “a working product” what’s meant is a functional, testable and maintainable product. Not just functional. If a piece of code provides the functionality required, but only the developer himself could read and understand how it does that, it is not a working product by Agile definitions. Developers are to get the code to work and then refactor till it’s readable, not duplicating code and as simple as it could be but not simpler.
Refactoring to make code readable, non-duplicative, simple and free of unused design complexities and code is a constant practice that developers are expected to follow whenever they code something.

The design focus of Agile is much more implied than explicit. In each iteration, Agile focus on getting a working product to the customer. The team narrows their focus only on the features that are planned for that iteration making it as simple and expressive as possible; yet not losing the overall picture - or at least what exist of it at the time. This practice makes sure that the design never gets complicated than necessary and serves to the problem at hand than expected (but volatile) problems of the future. One of the problems in designing the whole application at once is that the architect is force to foresee requirements of the future; with requirements ever changing and little understanding of them to begin with; this is not a task someone could get 100% right. That’s why Agile promotes this simplistic approach which could accommodate changes more easily.

Unit Tests for agile developers are a design practice than a verification step. Writing the non-compiling unit test is defining the contract for a component. Developer should do due diligence and consider who are the consumers and think how the consumers would want to use a class. Note that the tests are written for the public interface of the class, the tests care only about the functionality exposed through that. Once the developer get the unit tests to pass, he can then go on refactoring his code to be simple, readable and non-duplicative - one step at a time - without worrying about breaking the functionality unknowingly; because the tests are there to guard against that.

The next aspect of design developers ignore in Agile is how exactly the changes are accommodated. Remember that agile designs are as simple as possible meaning that when code is first written, it is not accommodating flexibility for “potential” change. But when the first change comes, the developers should follow the object oriented design principles and separate the changing elements of code from the non-changing elements of code, evolving the design in that part, so that a second change in the same area would be easier and simpler than the first. This practice prevents the code becoming stale over repeated changes, still keeping the code as simple as possible.

As always, developers should keep themselves up to date not only with the new technologies but of the time proven concepts; and the organizations who wish to harness the benefits of any methodology should invest on getting their developers in par with that methodology.


References
Agile Principles, Patterns, and Practices in C# By Robert C. Martin, Micah Martin
Agile Software Development: The Cooperative Game, Second Edition By Alistair Cockburn
Test-Driven Development By Example By Kent Beck

Yellow, Orange and Green

Kandyan Dancer

The specification of a method

Sometime back I read Alan Shalloway’s wonderful book “Design Patterns Explained: A New Perspective on Object-Oriented Design” which I think makes a wonderful pre-read for anyone who’s going to read the GoF design patterns book. But even if you’ve already read the GoF, like I had, Alan’s book still is a good read.

In that book, Alan brings the point that any object oriented software component should be looked at in three different perspectives,

• Concept - which is the responsibility of that particular component (i.e. what it’s supposed to do)
• Specification - which is the contract with the external entities (i.e. how it would be used)
• Implementation - which is how that component is actually going to get the job done.

At any given level of abstraction - application | component | package | class | method - this stands true and is very important to separate these concerns in designing at each level.

I'd like to give a thought on how this is applicable at the level of a method. Let’s take an example to make things easier to understand. A method that converts a string to a number.

What is the responsibility?
Convert a string to a number of cause, but does that statement describe everything?

What’s the contract?
Defining the contract is the step which is going to make the responsibility of the method more explicit, and define the explicit usage of the method.

What are the parameters the method would take? Just the string to be converted? Should it get control parameters?

What’s the format of the string should be?

What would the method return if the format is incorrect? Would it return a default value? Would it throw an exception (what type of exception) or would it return null?

What type is the number? Integer or float? Could it be both? If so, how would the method return it?

What’s the implementation?
We should only get at this once we have the answers to the above two questions. And our implementation should depend on them, the responsibility or the contract should not change by our implementation - remember the dependency inversion principle!

So why is this post called “The specification of a method”? Because that’s where I’d like to focus for the rest of this post. That’s where I see room for a lot of improvements.

How exactly do we define the contract for a method after we do have the answers to the questions like what we saw above? It should all end up in the method signature. But, most languages only allow us to specify parameters and return types; so how do we communicate exceptions and whether a method would return null or not?

Java is a language that goes one step further and offer checked exceptions that allow us to express in the method signature what type of exceptions are thrown by the method; which I learned to appreciate only very recently. That’s a feature which make sure an application will not ever crash due to an unhandled exception, by making method contracts explicit.

That’s one good example that making the contract explicit contributes directly towards application stability and better coding practice. (But there are debates on whether this is a good thing or a bad thing - I think it is good.)

How do we do this in .NET? We could add the exception details in the XML comment documentation. But that’s not as good as the compiler mandate of java.

The other part of the signature which we miss a lot is conveying the fact whether a method would return null or not. We see quite a few null reference exceptions and quite a few null checks on methods that do not return nulls than we would like to in our day-today life. Some argue that it’s a “good” practice to check null even if a return value cannot be null. But that’s a pretty lame claim isn't it?

There are two ways that I could think of to overcome this. Obviously we can comment if a null value is returned by the method. But there’s no guarantee that someone someday would forget the comment and would not check null. The much thoughtful approach is to implement the Special Case pattern (PoEAA). In which, separate implementations are given to such anomalies as null for the same interface, so that the consumer need not worry about exceptions. But, it’s a design decision that has to be taken much earlier than you start to design method signatures.

Regardless of how we are going to handle these information in the method signatures, if we do define them upfront and communicate to the consumers of the method (and of cause stick to that contract within the implementation) we are bound to improve stability and the quality of code in our applications.

Vesak is a Carnival

Seems it's finally over. There were insane number of people on the streets last week and traffic was horrible.

Apart from the traditional lanterns and lights, there were quite a few drunk men on the streets doing all sorts of drunken stuff and generally being assholes. I saw couple of musical shows, and a Ferris wheel in Dematagoda as well. Good Carnival, I thought - may be we'd compete with Rio someday and attract tourists.

I highly doubt, Buddha, the person who preached of simplicity and being unmoved by eight worldly dhammas would have appreciated this "carnival" and public menace to celebrate his birthday and attaining nibbana.

But who knows, Sinhala Buddhists(TM) have a strange way of practicing Buddhism...