Comments for Changelogic weblog

Comment on What you’ll write tomorrow is not what you think today by Imre Lumiste

Mon, 16 Oct 2006 12:42:01 +0000

Why should the internal backbone be public? The difference between public and private interface is huge in terms of flexibility, cost and need for documentation. Thus, making the API public still counts as a feature to me.

Comment on What you’ll write tomorrow is not what you think today by Manuel Chromatic Mayflower

Mon, 16 Oct 2006 11:32:33 +0000

Public API cannot be regarded as “any other feature”. It’s the backbone of your app and thus will always have at least one paying and highly participant customer - you yourself.

Comment on What you’ll write tomorrow is not what you think today by Karel Kravik

Mon, 09 Oct 2006 17:00:46 +0000

I’ve long ago trying to say (see the previous posts): “every feature you have means some other feature left out”.

Comment on What you’ll write tomorrow is not what you think today by Imre Lumiste

Mon, 09 Oct 2006 14:51:26 +0000

Sigmar:

this article was not meant to be anything personal, although yes, it has been inspired by some recent conversations.

Manuel:

any development decision should be justified by some business need. Our customers have the option to vote for having a public API by requesting for it. For some reason, they haven’t done it. Perhaps it’s because they have their own software to deliver. Or perhaps they trust us to deliver working solutions. As long as they don’t give us any requirements, how would we know what they need?

Designing, implementing, documenting, testing and maintaining a public API is a tremendous effort that requires development resources on expense of all the other features that our customers actually want.

So far, we have provided most API features that have been asked for; there are a couple of requests waiting in line exactly because there are other features that seem to be even more useful for our users.

Comment on What you’ll write tomorrow is not what you think today by Manuel Chromatic Mayflower

Mon, 09 Oct 2006 13:29:57 +0000

Well, why don’t you just label the public API as “provisional” and let your customers decide whether they want to depend on it today or not? If your heavily data-centric application can’t bear a public API after two-three years of development, you’re misguided anyways.

Comment on What you’ll write tomorrow is not what you think today by Sigmar

Mon, 09 Oct 2006 12:58:49 +0000

I think that the motivation for this article here came from Villu and ME , because I am one of these guys who like to make something for everything. And Villu is also making suggestions to make something for everything. Ok, I understand this what Imre tries to tell here. So, programmer should just understand, what is he(or she) doing at the moment: just adding or improving functionality or developing a framework or building an architecture:), and if he doesnt really understand it, then it’s boss’s job to point on it:)

Comment on Aim at a developer, shoot the team by AhtiK

Sun, 01 Oct 2006 19:46:46 +0000

I see blaming often as an inhumane and unprofessional way of trying to urge people to find the real cause.

“What went wrong, how can we improve ourselves next time?”
vs
“You have 50% of bugs still unfixed and we supposed to be live since yesterday and client is paying less than we pay you and your shirt stinks!”

Blaming is like irrogant problem statement without cause-analysis from a distance and doing this in a bossy way

Comment on Aim at a developer, shoot the team by Blanka

Tue, 26 Sep 2006 11:59:14 +0000

Blaming and punishing should really be the last option. The worst about it is that is sends this message to the team: don’t try anything new because if you fail for any reason, you will be punished. Why should someone give the very best of him, his creativity, for a fair chance to be ridiculed later?

Comment on Aim at a developer, shoot the team by Tim Williscroft

Mon, 25 Sep 2006 22:16:26 +0000

You might find solace in the works of W Edawards Deming.
(The TQM guy)
The first rule of TQM is “Drive out fear”

It works for manufacturing, why couldn’t it work for software.

Comment on Aim at a developer, shoot the team by Kristjan Kanarik

Mon, 25 Sep 2006 10:12:50 +0000

Right on point, Imre. During last 10 months I’ve been in a major client facing role (analyst/PM) and when something has gone wrong, I’ve been asked a number of times “how could that have happened? who is to blame?”. I mean, come on, does someone actually include “looking for victims and punishing them, softly” as an activity in the project plan? Not so.

Same goes for any other activity that hasn’t been planned for - even refactoring which Karel has bashed about, endless optimizing (probably Karel has bashed about that as well! etc. If it isn’t sensible (doesn’t create value for the customer), don’t do it.