Tag Archives: agile

We don’t need another hero!

Hero developers. That breed of super heroes that solve every damn coding problem that arises in our software projects. They are fast, and usually they complement it with lateral thinking, boosting their quickness with solutions that seems taken out of a magic hat. And it seems they are always there when we need them. They have a great commitment to the project, they love to save the day, even on weekends! They seem to have an affinity with programming languages, they even understand the ones they have never seen before… and quickly.

New requirements enter the show with no adjustment in schedule? – No problem, we have Superjavaman with us!

Bugs, bugs and more bugs!!! What are you doing people? PHPman, here… take the key of the office. Stay this weekend, please. We need to be ready to deploy on Monday! Refactor anything you want, I don’t care, but make it work! Oh… yes, and turn off the lights when you finish. Thanks!

Client: “What? I didn’t mean only A and B… What I meant was that we need the app to do A, B, C, D, E, and all the remaining letters of the alphabet!” – Team Leader: Uuuups… better start lightning the C#Signal, we are gonna need Supersharpy right now!

This guys are really great. It’s always nice to have one of them in the team.

But guess what?… If you need heros more than once in a while… you suck as project leader!

Yes, and I’m sorry to tell you this, but it’s true. Don’t take it personally. I have fall into the hero trap myself more than once, so I’m also talking about my own problems here. When a software project has problems, they are usually caused by a bad leadership, and not because of bad developers.

Of course, this is not the way that project leaders want to put it.

“Hey, project leaders don’t code, so why are they responsible of bugs?.”

“Project leaders are not the client, they are not to blame for those unintelligible requirements. The client is!”

“Wait a minute… as a project leader I usually double check all time estimates with a developer, so I’m not the one to blame about bad schedules.”

Really? Is that easy? Are developers so awfully bad coders that they introduce bugs in every code they touch? And if it’s so… you didn’t notice until well advanced in the project schedule?

Aren’t project leaders the responsible of the project, including understanding what the client wants? And if this is not clear enough, don’t they have the responsibility of at least communicate this to the client and try to solve the issue?

Do project leaders come from a parallel universe where time works different than here? Why they can’t understand that time estimates are only that… estimates, not promises? It seems to me that not matter if the project leader was a developer just until yesterday… today is project leader, and now he forgot that a good time estimate requires time. You need to know exactly what you have to do in order to tell accurately how much time is going to take. More time, better estimates; less time, worse estimates.

And all this gets worse at corporate levels. Usually at big companies every one functions in Pontius Pilatus mode, trying to avoid responsibility of any decision. They only lack the water bowl… but if they could have one, the picture would be complete! (I guess that I’m going to code a mobile app of a water bowl, so every time this guys have to take a decision, they can tap the bowl and a voice in latin says something like “The decision is yours… not mine….”).

So please… we really don’t need another hero. We need common, normal, ordinary developers who work good enough to get the job done. But what we really need is good project leaders. The ones that know that software development is a team effort, and know how to facilitate the workflow between team members. The ones that helps them solve problems, and that take the rocks out of the road, not the other way around!

Is your responsibility as project leader to make your team fit together, and to help them not to loose focus in unimportant tasks. Bugs are your responsibility… just ask developers why they have them, and if there is something you can do to help. Requirements are your responsibility… so be sure that everyone understands exactly what has to be done. Schedule is your responsibility… so take the action needed to make the client understand what an estimate means, and don’t fall into the “Holy Bible Syndrome”. And last but not least… please, hear what developers warn you about, they usually make their warnings when there is enough time to do something. If they talk… listen.

So here ends the software development catharsis… After all this, I’m just hoping that I have some readers old enough to remember this:

We Don't Need Another Hero (Thunderdome) by Tina Turner – www.musicasparabaixar.org on Grooveshark

Mad Max: Beyond Thunderdome

Mad Max: Beyond Thunderdome

The case against functional specs

Stack of Documents

Stack of Documents

Is there any single way in which you can develop a piece of software that doesn’t do what users want? Yes, write a functional specification document!

Before saying anything else, I want to clarify that I’m talking about typical software projects… web, desktop or mobile apps; not about space shuttle operating systems, or real time controllers for robots that do brain surgery!

I can almost hear all of those functional spec lovers yelling all kind of things at me. – “Are you crazy? Functional specs are supposed to help us in delivering good software, products that do what the users want.” Well… usually we achieve exactly the opposite by creating this documents.

This is one of those areas where reality shows us again and again, how wrong we are.

Please, try to remember any software that you have developed, that once it was finished, still kept quite close to the initial functional spec… I couldn’t. And I know a lot of good software developers with this same dilema. The reason is simple, functional specs are theory, not reality. Of course, we could try to maintain them close to reality and in tune with all the changes and evolutions as we develop the software, forcing us to strictly change first the specs before doing anything else. But then… why bother? Isn’t it supposed to help us? If we have to change it day in and day out, every time we want to make changes, does it worth it? Does it slow us down?

In my own experience with all the corporate clients that I worked for, they always had required some kind of detailed functional spec before starting to build the software. The best scenario was to have a software very different to the initial spec, but fortunately aligned to the client needs. Sometimes these specs where updated, sometimes not. But we always had a lot of overhead with back and forth discussions with clients about what was a “requirement change” and what was a “misinterpreted requirement”, and then rewriting the specs or writing new ones.

And the worst case scenario? Well… if those were some of the best cases, I guess is not necessary to explain what happened when we weren’t so fortunate.

Over the years I came to discover some truths about software development and functional specs, the hard way… hitting my face over the wall. Most of these issues were addressed by other people, and I only wish now that I could had the chance to understand them better back then:

  • People don’t understand specs the same way. Every time you write a spec, you’ll have people thinking different things about the same issue. I saw this happening a lot of times. Even with a paragraph of 1 sentence. There’s always information that’s implicit and existing only in the brain of one person. And of course that information is obvious for this person, but not for all the others.
  • There’s not enough information to make the real decisions at the time you are writing a spec. Usually the information needed arises once you start the development process. So here we are playing with guesses and assumptions, not making any progress at all, and usually discussing things that will not apply later on.
  • At spec time, there is always the tendency to add a lot more functionality that what is really needed, and what it could be built with the available time, budget and resources. People (and usually programmers too! -yes they are different kind of animal-) like to add a lot of functionality to software, because… – “it’s only a button here and there, how much could that cost?”, or… “yes, we need categories and subcategories for this, and would be nice if they could be user defined. This is just two simple drop down lists, very easy right?”. Until you start thinking about all the support code, CRUDs for those “simple” drop downs, tests for the new modules, new deployment code, migrations for the old data to upgrade to the new software version, etc. What seems simple and tiny, almost always grows bigger when you start building it. And of course, the budget is already written in stone!
  • It’s very easy to fall into “Holy Bible syndrome”. Specs are usually used as signed contracts. And once you are there, it’s really difficult to build a useful software. Reality is always changing, signed contracts are just the opposite, always fighting against change (and both sides of the contract, client and provider, in alternating times, assume the “not change allowed” role). I’m not advocating here against software development contracts or trying to evade responsibility and accountability for what developers produce. But transforming a software spec in a kind of Holy Bible it’s not going to solve the real situation that presents every day in these industry: perpetual change. When we use the specs as a signed contract, we loose a lot of time and effort dealing with which changes are allowed or not, with interpretation details of what was asked to do, what was “in there” and what wasn’t. This is dead time. Assume reality, and please work as a team with the same objective: build a useful software.

“So great genius… if we create no spec, how do we start? Do you suggest start coding right from the beginning?”

No, not at all. But I’m for things that really help you build your software, and don’t get in your way. What I really found that works is to start with a really small description of the product or software that you want to build and some UI draft sketches. This will really help you visualize the software you want to build, and to communicate the ideas easy and with low overhead between team members and with your client. The natural evolution of these steps is to start building the real UI, with no functionality.

“Hey! Wait a minute… isn’t that a kind of spec?”. Yes it is, but a different breed. One which is simple and agile enough to help you and your client to agree, and to move on to the real work… getting the product done! I’ll be writing about this process on some future post.

From my own experience, I got the bests results when I kept focused on less documents, more agility, and using the right tool for the job.