Tag Archives: management

How to choose when to start a project

I have observed this happen several times: a development team or teams are busy working on several projects and are fully occupied. Suddenly management thinks of an attractive new project and want it to be done quickly.

What happens next?

What should happen next is:

  1. Remind themselves that change is necessary and good, but change has to be managed, not random
  2. Do some ball park cost-benefit estimate of the new project
  3. Review the list of projects being executed and in the pipe-line
  4. Decide whether (a) new resources should be hired for the new project; (b) some current project is not necessary or of lower value and delay or cancel it
  5. If choosing to delay an on-going project, take into account that when a project is stopped and then re-started later it usually takes longer to do (ramp up time) and might also have lower quality (loss of momemtum/enthusiasm)
  6. announce the decision to the existing members of the project?

The many faces of a software project

project.jpg JPEG Image, 800×600 pixels.

The mirage of software estimation

Friend sent in a link:

Subject: Why software estimation is so difficult
Or are we just bad at it.
Finally some mathematical rigor to it:
http://www.idiom.com/~zilla/Work/kcsest.pdf

A necessarily incomplete excerpt from the introduction of the paper:

… Is it possible to apply mathematical and scientific principles to software estimation, so that development schedules, productivity, and quality might be objectively ascertained or estimated rather than being a matter of opinion?

And can we do it in a way that does not take longer than, uh, doing the project itself? It would be even better if it did not take longer than the boss/customer/client takes to blow their collective tops.

… there are a large number of design methods, development processes, and programming methodologies that claim or hint at objective estimation of development schedules, project complexity, and programmer productivity. …

Yup, got that right.

Hardly any methodology comes up and honestly claims that the estimates are going to be rather shaky. There are those that emphasize change management and re-estimation as you go along. However, they blame it on “changing requirements” or “project risks”, not on “our estimates are way inaccurate anyway”.  Hardly anybody acknowledges that estimating how many tasks can be done in a sprint, or how long a sprint will take to do is a guesstimate. Instead, they just downplay the estimation bit, to a bullet point in a presentation: “thou shalt estimate thy tasks”. You come away thinking there must be something everyone else knows about making accurate estimates and you are the only idiot on the planet who does not.

… it would be easy to conclude that these methods are not being practiced.

Yeah, not in very many places. Just adopt a methodology and your schedules will all come out just right.

In sections three and four we will find that algorithmic complexity results can be directly interpreted as indicating that software complexity, development schedules, and productivity cannot be objectively and feasibly estimated and so will remain a matter of opinion. …. The situation here [with approximate and statistical estimators] is more optimistic, but we give reasons for maintaining a scepticism towards overly optimistic claims of estimation accuracy.

Well, that was that. No accurate estimates for you. Schedules are just guesswork.

In all the project management literature I have read, the work of project management consists of a lot of tasks or processes, and one teeny-weeny box in the big flow is “activity duration estimation”. And I have not seen a single description of actually how to go about doing it.

The PMBOK (Project Management Body of Knowledge) produced by the pmi (http://www.pmi.org) has more to say: it described the inputs and the outputs of the process of “activity duration estimation” and the tools to do it:

  • Enterprise Environmental Factors (that is, everything about how the company does business)
  • Organizational Process Assets (aka Historical Information)
  • Expert Judgment

Wow. Expert Judgment. Hmm…. that reminds me:

Once, I was trying and failing to setup networking on Windows on a home machine. When I reluctantly fired up the help system by clicking on the “Troubleshooting” link on the networking tab, I was walked through some inane Q&A menus, finally landing on “for more information, ask the system administrator of the network”. You can see this kind of “help” in a lot of places, including user manuals.

The alleged system administrator is the equivalent of the “Expert” of the project management lore, one who would have the knowhow to give accurate, useful information.

The problem: I was the system administrator of the network. And I did not (yet) have a clue!

Software is knowledge

People screaming about software engineering were pulling the wool over our eyes and trying to make a quick buck, all along, as we all suspected when we attended those boring software engineering classes in CS courses.

Robert Glass got it right. Software is NOT an artifact of engineering. Making software is not like making a bridge.

Software is an embodiment of knowledge. Executable knowledge. Knowledge that when pasted over some silicon and stimulated with electricity can cause things to happen. By itself very little beyond flipping voltage levels in areas of said silicon. But give it some tools (like a serial port, cable and lcd screen) and it can communicate. Give it more tools (serial port, cable, robot arm) and it can create physical changes in its environment.

Yeah, you got it. Software is less like a scalpel, more like a doctor.

Why the sudden light?

Well, I was trying to document high-availability solutions with MySQL. When going through the nitty-gritty of MySQL Cluster’s limitations (no offense intended: it is probably a good product; I am not dissing the software) it occured to me that they warranted noting down, so that my team would not have to read so much should they deal with MySQL Cluster. I found myself writing a short note with a link to the original page for details, because I felt that I could not tell the whole truth in a shorter way, and copying and pasting would be a waste. So, my documentation is a little more than some summary notes peppered with links to the full documentation.

Anyone reading any code that tried to deal with the limitations above—written in an arguably already readable language—would still scratch their heads at why some weird stuff was being done. There would have to be comments explaining why this was done. The comment could be just a link to the MySQL documentation page. Or, it could have the full explanation, with the MySQL version in which said limitation lurked. Or both. The person reading the code would have to understand the documentation before they could say they understood the code.

The point is that: if there is good documentation about some topic, I can do little than point others to it and say “this is important”. The documentation is the communication.

And the more important point is: you cannot claim to have understood a software unless you understand its intention and motivation. And in the above case, the motivation means reading the documentation. Most times, reading documentation means you come back with knowledge. In other words, to understand the software, you must, well, understand. Err.. I mean, you must acquire the knowledge the original developer had when creating the software.

Which brings me to a wicked question: the reason I was writing the original notes about clustering was so that not everyone in my team has to know the nitty-gritty and just know enough to design and write code to be handle clusters if we decided to use clusters. But it looks like no one can actually decide if the code will be right without having read the full documentation anyway.

What about code? That’s worse. You now must understand the intention of the code. Then you must understand the motivation behind the code. To do that you must read the documentation.

Software is knowledge.

And my documentation is little more than a reminder note or a collection of related links.

Singapore Entreupreneur Web 2.0 Unconference

Choon Keat came around at work to remind me of this unconference. I’d wanted to attend and therefore we both left together. CK was a bit surprised at the number of people there—ought to be close to 200—because the last time he had attended it, it was a small group in a “pathetic room with pizza and beer on the side”.

What intrigued me about this event was the format. The self-styled unconference claims to have an informal setting where many parallel discussions are going on side by side and where you are either presenting, debating or absorbing. Should you be not doing any of these, you are supposed to use the Law of Two Feet to take yourself elsewhere where you can be useful.

It wasn’t quite like that. This is the fourth instalment of the event, and this is the first time the organizers were trying to have three “tracks”. IMHO the tracks made it all too formal, because I was scientifically trying to decide how to split my time instead of just popping in at different talks and seeing whether something interesting was going on. Still, not having attended the previous events, I can’t compare and this may very well be a good format.

There was lots to hear, see and talk about. The debate was sometimes spirited and people were not afraid to speak. The questions (to presenters from startups) came fast and the presenters were able to roll with the punches.

The first presentation I attended was from a startup called ActiveDeals which puts movies in your MSN with some advertising along with it. It claims its product is interactive TV, about which I could only make out that people could chat about the video they were seeing with their friends and (presumably) on their website. If there is more interactivity the presented did not say. Haven’t fully checked it out yet, but this is the kind of startup that depends a lot on execution and the main barrier to entry is the work to get there. Their main points were:

  • The videos would be short, on-demand, and focus on local stuff; something people would be comfortable watching as a short break at work;
  • The interactive options would lead to user-generated content: links, reviews, etc., which could then be linked against the videos and become content.
  • activedeals would be doing the video production, so that’s some leg work.
  • Sponsorship of the video content would pay the bills.
  • The sponsors would have to be educated to the use the interactivity of the medium as opposed to just sell, sell, sell.

I don’t know how far they have come along—there were some mockups in the presentation, and the presenter Todd Murray referred to them as such—but the presenter mentioned they would launch in March.

I attended only 5 minutes of the next presentation, which about a website called Wisheus. Here you can “publish your wishes and your wares”. It might attract some teens. Could not see whats new about it. But I’ve not tried to sign-in, and I did not sit through the whole presentation, so if it has some twist, I don’t know about it.

I quit this talk to go to another about complex-systems and networks. The presentation started out with fractals, then on to complex systems with emergent behaviour (you know, the ones where autonomous agents which have simple behavioural rules but can interact with each other, produce complex, unpredictable behaviour), and then on to networks. Finished off with the observation that by observing a network, one could find out those nodes which are highly influential. For e.g., in the blogospere, there could be a blogger who is connected to just the right people and has interest in the idea you wish to popularize. This blogger does not have to be an A-list blogger with lots of readership, just rightly connected. Okay, but the relationship with fractals or complex systems is tenuous. The talk could have been better.

The next talk was titled “The Two Towers (of Web 2.0)”. I walked in a little bit late and heard people going on about Ajax. Asked someone what the other pillar was, and heard that one pillar was not ajax but technology and the other was marketing. Marketing? Well… not surprising considering that the talk was anchored by a group called Singapore Entrepreneurs, a group that runs a blog and also provides vc funcding in some way. I chipped in with an observation that while Ajax is a great technology enabler, another interesting aspect is the opening of the web as services with APIs through which people create and transform existing content into new forms. Guess people did not like it.

The only interesting points in this talk were that singapore is not ready for web 2.0 and that the talk should have been about doing stuff, not about whether we can or should do it. The rest of the time was spent in regurgigating stuff from techcrunch.com (did not know it was so popular), and blaming timid singaporean VCs.

The next talk I was interested in attending was by Yahoo about widgets and gadgets. But at this point I had to leave.

Interesting event and I look forward to attending more. If I could stand up to the barrage of questions that other starter-uppers got then I would be proud of my pitching skills (don’t have any, I think). I do hope the level of the discussion goes up a little bit. It is most interesting when people talk about local circumstances and local problems and not debate about whether Singapore is too small. It is. Apparently some people want to start-up anyway. What could they do better?

GPACS: when to refactor

Here is a situation:

  • You are working on specs for the next sprint and they are not complete;
  • You are considering a new technology to replace one you are using;
  • Experimentation has shown that it is good.

I say, take the time to refactor! Use whatever knowledge you have now. Don’t overdo it, because the new specs may call for some changes.

People struggle to allocate time to refactor. One should do it whenever one can. Especially when:

  • You have time on your hands;
  • You know going forward you will be using the new tech
  • You have the luxury of replacing some tech with another without simultaneously having to deal with changing requirements (at least while you are doing the replacement).

Does it also help not to have to think about the future design, while you are re-factoring something in the current design? Sometimes I think one needs to consciously choose to juggle only one variable at a time.

Keeping the fires fed

I did a mid-sprint review yesterday. Work seemed to be going on at a rapid clip, even when some developers were involved in support activities or other projects. What I realized is that a steady stream of well-defined work activities keeps people occupied, purposeful, and productive.

Where does re-design fit into this? When people start thinking about design or design changes, I’ve noticed that sometimes very blue-sky ideas come in. The good part is that the design might be very good (although most often it is hard to tell whether a design idea is significantly better that what you already have).

The way to control design efforts to be useful, incremental and low-risk is to—probably—focus on implementing some part of a use case. Design can then evolve.

Of course, radically new design may need re-writes
and revolution, not evolution, may be the way to go. But that way lies risk without the certainty that the new design would lead to a significantly improved situation. Especially in the face of evolving requirements.

GPACS: the early days

GPACS is the company‘s accepted software development process. It is a quite like Scrum. More about it at some other time. The point is that I am managing an enhancements to an existing software while also considering re-doing or modifying it for some new requirements. One of the first things I need to plan is to how to get various teams working together. The other thing I need to figure out is to how can the same team work simultaneously on “enhancements” to existing code-base while trying to implement something that has a slightly different set of requirements.
.
I came across a bunch of articles by Chad Fowler: “The big rewrite”.
And then another article
by someone called Kevin Barnes.

Oh, I was already thinking that a complete rewrite was out of the question because of the risks involved. But I could not have listed down the issues/risks as well as these two articles have.

powered by performancing firefox

Tenth deadly sins of project planning

In an IEEE Software ‘From the Editor’ column, Steve McConnell writes (at http://www.stevemcconnell.com/ieeesoftware/eic19.htm), that the nine deadly sins of project planning are:



(1) Not planning at all

(2) Failing to account for all project activities

(3) Failure to plan for risk

(4) Using the same plan for every project

(5) Applying pre-packaged plans indiscriminately

(6) Allowing a plan to diverge from project reality

(7) Planning in too much detail too soon

(8) Planning to catch up later

(9) Not learning from past planning sins



I am managing a project right now, and I just can’t figure out which sin I am committing: (2) or (7)? I suppose the answer is that is depends on the project and its circumstances. But of course. It always does.



And uh, so at least now I know that these are all the deadly sins of project planning and other sins are presumably not deadly. They are merely extremely toxic, presumably. My project won’t exactly die if I forget about some other practical issues, it will just go into convulsions or stop breathing for a while, or sway gently from side to side when it should be rocking.



In other words, I still have to worry about the non-fatal issues in some particular order which is highly project dependent, and these so called fatal sins have to watched out for but exactly when a sin is being committed is also dependent on the project.



Duh!



Why do these wise men write these articles with zero information? I just wasted a perfectly good 5 mins which I could have spent more usefully reading about a API, framework, or some such, that would actually have solved a few real problems.



The tenth deadly sin of project management: trying to get wisdom from anything other than hard facts when you should be doing project management: learning, building consensus, disseminating information, talking to your team, and writing code.











powered by performancing firefox