Month: April 2006

Categories
Technology

It’s all in the estimate

Estimates form the basis for all software projects. In fact, estimates are part and parcel of our daily lives. We live, plan and act by them. Our expectations are met or shattered based on the estimates we feed into our lives.

Buying food, you might estimate before you set out how much money you need, how long you think you might be and plan supper, a night out, a telephone call based on the estimates you give yourself. When life goes according to our estimates, we’re happy. Everything is running smoothly. When estimates are wrong, we adjust, but sometimes, the ability a bad estimate has to flap it’s wings and spiral out of control can be deadly. Especially for a software project.

Based on estimates, business programmes are set in motion. Budgets are approved and marketing plans are established. The length of the estimate is largely irrelevant. What’s critical is its accuracy. When projects, and hence people’s careers, lives, finances, lifestyles, families, are on the line [ok, maybe a tad dramatic :)], an estimate has the misfortune of not being taken too seriously on one hand, or far too seriously on the other.

Taken too seriously and the time to estimate can be as long as the time to do. Not taken seriously and the time to do is incalculably longer than the time to estimate.

And because estimates can be co critical, it does make sense that the right amount of energy
be invested into getting them as accurate as they need to be, weighed against the cost of getting them too accurate. No solution strategy, technology or skill set is going to set you up professionally if you don’t know how long it’s going to take you to do something, do anything. If you don’t really know how long it will take, it does imply that you don’t really know what you’re doing. And if you establish a trend over time of not delivering when you say you will it shouldn’t come as a surprise if your services become undervalued.

Of course, you can always “buffer” your estimates and play it safe. But in a dog-eat-dog world where the ubiquitous “5-minute solution” marketing threatens your chances of being awarded the contract [or the glory- however inaccurate those 5 minutes are], buffering can be expensive.

Considering the risks, together with the cost of not being accurate, it pays dividends to be more boldly accurate. And to be more boldly accurate, it takes time invested into getting to know your weaknesses. It takes being honest with your progress using feedback mechanisms that might hurt your feelings. It requires that you get better, not just at what you do, but at how you do what you do.

Categories
Business perspective Technology

Beautiful Programming

With a mission statement which includes phrases such as creating beautiful software and a focus on beautiful people, it can sometimes be hard to follow such a mission if the very objective, beauty, is hard to materialize.

It has been said that beauty is in proportions. The moment you start emphasizing or leaning too heavily on one concept, you start to caricature the concept and fade on beauty. Beauty is all about holding the right proportion at all times.

Beautiful software does not waste features, but has everything you need. The interface is not busy but practical. Its efficient and natural, but cruising through complex problems. The code is not bloated and not cryptic due to code line famines. It has the right proportions. Beautiful people are controlled but not retentive. They are passionate but not sentimental. Expression is a skill, not a habit. Focused yet continually thinking out the box. Pushing boundaries and pioneering but never falling off the edge, beautiful people contain the right proportions. Bringing the two together is indeed a mission statement, but requires more mission and less statement. And to achieve this, we use the inaptly and irony-burdened name Extreme Programming.

In its essence, it aims to contain proportion, never to focus on the extremes. The right design, but simple enough and agile to tackle complex systems. Estimating to cater for business forecasting and survival but not allowing dogmatic routines and methodologies to dictate. Indeed, a minefield of contradictions when you lean too heavily on the one concept to the neglect of the other supporting principles but by achieving the right proportions and you attain beauty. Perhaps we could reconsider the term Extreme Programming (afterall, its laden with cliches and prejudices) and look at the ways we want to work and what we want to achieve. And never forgetting, most importantly, how we want to achieve it. Perhaps, the way we implement our mission is more suited to the title Beautiful Programming because beautiful software, created
by beautiful people can only be created in a beautiful manner.

Categories
perspective Technology

The Agile Debate

There are two main schools of software development: those that love agile processes and those that don’t. Of course, there could be those that couldn’t care either way….
And both have very convincing arguments and both can be as passionate about their own [dis]beliefs. But just as soon as somebody hails a solution to our problems, there’s already another gang crying that the solution is the problem, or is the bigger evil of the available problem domains.

Wether you like agile process or not, benefit from mechanics of pair-programming or not, have had your ass quite literally saved by TDD or not… there will always be a process that you follow, however loosely [or not] defined and [not-so] obvious to the rest of the world. It is amazing how the n-schools of thought justify their existence by the apparent shortcomings of another. This is no surprise since the world operates in this fashion. Democracy rules because of the evils of autocracy. And vice-versa. There are not many, if any, systems which are self-justified. Agile processes rule because of the shortcomings of traditional development processes. Traditional development approaches rule because the alternatives don’t work. This is the mindset that pervades the path we choose.

The irony is is that if it works for one, it’s because it just works in that time and space for that collective group of people. Does it mean that it will work for another group of people, on a different project, with a different skill set and varying group dynamics? Of course, you’re welcome to say it will. You can also say it won’t. In other words, you can speculate. But no amount of speculation will justify how right or wrong you are about another group’s implemenation [interpretation] of the same principles.

What works for one project works because the people on that project make it work. What doesn’t work, simply doesn’t work. None are so blind and deaf… And with methodology, nothing will make it fail as much as those who don’t want it to succeed.

Categories
perspective Technology

Crossing the Line

There’s always a line waiting to be crossed. Morally, technically, physically. With whatever we do, or can do, there will be a line. And some of us will cross that line just because we can. It doesn’t mean though that we should.

We can cram a plethora of features into any software product. Doesn’t mean we should.
We can add layers of indirection into our architecture to push the boundaries of decoupling. Doesn’t mean we should.
We can implement [insert pattern name here]. Doesn’t mean we should.
We can deprive ourselves of sleep and turn a 4 day project into a 2 day delivery. Doesn’t mean we should.
Just because we can, it doesn’t mean we should.

Too many decisions are implemented based on what we can do. Usually there is some discussion about what is possible and what is not. Wether or not it makes sense, is not beside the point but can certainly be diluted by confusion amidst emotional rhetoric. And then after all is said and done, there being no obvious agreement, a public opinion poll is held. Oh behold the saviour of our modern thought process: public opinion. It has been said that public opinion is no substitute for thought. Behaviour beg to differ.

Of course, the problem with lines is that we often don’t know what the other side is like or where that line was actually drawn. It’s only once we’ve crossed it, do we realise that we’ve crossed it. At such times, realization and prompt action can help alleviate any problem caused by being on the wrong side. It does take some courage; different to bravado which is usually what crosses the line in the first place. Itself, another line: bravado and courage.

Recognising where the line is and if it’s worth crossing is a valuable skill. It’s the difference between profit and loss. Value and gimmick. Genius or just clever. Working hard or working smart. If there’s one soft skill your team can encourage, it’s line detection.

Categories
Technology

Parameter Guardians

With most methods that are called, procedural or OO, there will be (a) parameter(s) passed in. The parameter itself can be a relatively “simple” type [eg. int] or a more complex reference type [eg. string]. The degrees of simplicity referred to here are related to the degrees of state which a parameter can have.

In the case of an int, the value must be set and the range is within an established, and ususally guarded, boundary. In other words, an int has a set size limit and cannot be null. A string, however, can be null and can be of *mostly* any length [physical memory aside]. There are other examples of the relative complexities of parameter types, but these suffice for the discussion. Which is to say, there are relative degrees of complexities in dealing with various parameter types.

In dealing with the various types, there is a responsibility, somewhere between caller and callee, about ensuring the state of the more complex types. In defensive programming, the responsibility lies more with the callee. Should a callee accept a reference type [eg. pointer, string, object reference] it is the responsibility of the callee to validate the state of the parameter before using it. Consider…

public void foo(string param)

Here, foo must check for:

null == param

or

param.length > 0

or any other explicit constraints about the contents of param which are not essential to the function. In doing so, not only is foo concerned with doing what it needs to do, it also needs to check what it receives before it can function. On the plus, foo documents it’s assumptions about the state of the parameters it functions on. On the drawback, foo also has the responsibility of dealing with bad parameters, in addition to its designed function. In fact, what does foo do if param is NULL. Throw an exception? Conditionally process the function?

If it throws an exception, why check for the state of the parameter anyway since using the parameter in a null state will generate a more reliable[?] exception. Is a system generated exception more accurate than the programmer’s interpretation of a bad parameter. And which is more liable to remain accurate for the lifetime of a function?

Conditionally processing a function can be ambiguous and overloading functions might be a more explicit way to dealing with “conditional” parameters, depending on your design. Also, simply returning from a function because the parameter is not what is expected can also be a design
issue and not completely within the scope of this discussion. The main issue revolves around why should a callee guard against the state of the parameters it receives?

Wether the callee throws its own exception or lets the system throw, the caller is still responsible for handling the exception- or ignoring it. Either way, the caller has expectations about the state of the system [and the parameters] before and after making the call. Those expectations cannot be met if the caller itself is not aware of the state of the parameters it is passing on. If the caller is aware that the parameter it is about to pass is NULL, it shouldn’t pass the parameter unless it knows that itself and the callee both assume NULL is a possibility.

I maintain callers have the responsibility of passing “good” data [garbage in, garbage out] to any method. This makes for a cleaner design in the methods since they work within reasonable assumptions and their code is not dotted with “unneccessary” checks which should have been proactively made further up the call stack [read: closer to the actual problem]. By burdening the callee with the responsibility of not being “open to abuse” is relegating the problem because then i would ask the question: why is the callee being abused to begin with? Surely the real problem lies somwehere else?

But then again, does it hurt that much to put the extra checks in on the callee, as per good defensive programming techniques suggest? Certainly for security reasons, there are certain methods which simply must check their data because they don’t trust anyone calling them. And that too is only by way of design. So in addition to callers being responsible, there are times when the callee has more of the responsibility. Combining the two views, and after a brief, no less passionate debate about the matter with Eugene…

as soon as there is enough information available to make an intelligent assumption about the data you are working with, you should. Be it caller or callee.