What to do if one detects flaw in architecture of the software

Question

Currently our team of 11 people is working on a project on asp.net platform. Timeline for the project is of 8 months and we have already done 4 months. Now working on new functionalities we find that there are some flaws in the architecture of the system due to which we are facing lot of problems. Now whom to look-up for solving this ... the Team Lead or the Project Manager... Have you ever faced this scenario ? What is the best to do then..

Answer 1

Just put up your issues in the team meeting that involves both the team lead and the project manager. Put forward all your views frankly and effectively. This would in turn help the future of the project and give a new insight to the PM.

Further all the 11 team members too can discuss this among themselves and share one another views.. not just about the problem... but also about the possible solution. In the end share all the valid solutions to the TL and PM. This whole process would eventually help to recover the project from this mid-development issues.

A good link for what to do is this

Answer 2

Raise the matter to your project manager. Present a list of options with as best an estimate as possible for time to complete each with an objective list of pros and cons.

Offer your advice as best you can, but at the end of the day it's probably not your call to make on which way it will be resolved.

Answer 3

For what you say it seems you have a Technical Debt.

That's a problem that every project faces, mainly because now yo have much more knowledge of the domain than 4 months before.

It's a tradeoff, if the changes are not very brutal you might pull them off. If they are radical, you might reach the deadline with some of the features and then schedule time for refactoring.

Remember, as real debt it will keep growing interests until you pay it off.

Good luck!

Answer 4

I'd start by getting a consensus across the team of what the issues are, and how they might be resolved. Ask yourselves: What's the overall impact? Is it a complete roadblock? Are there ways around the issues without having to make major changes? It might not be too serious, and by discussing the issues you might be able to agree an quick resolution.

Answer 5

If you've realised this and no one else has, and you want the project to succeed, then it's up to you to put a few extra hours in and figure out a plan, and then sell it to the people who are nominally responsible for the decision making.

Real projects do have "restarts". It doesn't mean that you throw away all your existing work. It means you find a new shell to fit pieces of that work into. This is a lot easier if your work-so-far consists of well-understood self-cohesive little components, loosely coupled with each other. This is why people work that way - because they know from experience that they're going to have to rearrange things. Almost all features added to programming languages over the decades are due to the fact that we know each chunk of code we write may be in for a choppy voyage - it may survive, but will probably have to cope with a lot of unfamiliar environments on the journey to release.

So you've noticed that relevant information emerges continuously, throughout a project. It doesn't conveniently all show up in a single burst right before you start typing code. Writing a specification document doesn't solve this problem at all. So you need to change the way you work so that the project draws in new information all the time - new emerging information from outside is the food that drives your project forward. Try to look forward to each new surprising revelation and greet it as a friend!

What does this mean? It means that the "architecture" parts of a project are no more stable than the "little details". You have to be able to change the architecture. You don't have enough information at the start to make a permanent decision about anything.

The underlying problem may be the fact that you have an eight month project in the first place. Real eight month projects (ones that succeed on time) are actually, if you look closely, a lot of shorter projects: 16 two week projects is ideal.

You need to put all the project's aims (so far) into a big list in priority order. Write each feature requirement from the user's perspective. "The user must be able to blah blah blah", that kind of thing. Avoid talking about the technical issues of the current design. Think about how a user would deal with having no product at all (or whatever they currently use) and talk about how their experience would be improved by a particular feature.

The important thing is the priority order. The aim is to be able to say: we only have time to ship with the first 10 items done. That's better than 9 items, which in turn is better than 8, and so on. But even with 8 items it would be better than nothing, because each item is a feature that by itself would improve the user's experience.

The list is called the backlog.

If you compare your work so far with the backlog, you'll typically find that you've been working on low priority stuff, because you imagine you'll need it later. Try not to do that from now on. The low priority stuff is... low priority. What if some new higher priority requests emerge between now and ship date? They almost certainly will! Despite what some people will claim ("It will be totally useless without feature A!"), you could probably ship with neither feature A nor feature B. But if you had to pick one, you'd go with feature A. And you may well have to ship without feature B, due to lack of time. So don't jeopardise A for the sake of being "ready" for adding B later. Only prepare in advance if it costs you next-to-nothing - leave places where you can add things, make everything extensible, but not if it slows you down right now.

Then start working on a new version of the product (cannibalising the work done so far where it makes sense) that takes care of the first few items on the list - the bare minimum. Spend no more than a week on this. A week is 6.25% of your remaining time, so it's actually pretty expensive. But at the end of this you have a picture of what you're ready to ship so far. That is the only way to measure your progress from now on.

The rest of your project consists of:

1. Repeatedly cranking out new working versions of the product, each time adding a few more features from the priority list. Get a small community of users to work with each version and give direct feedback to your team. Aim to do a new version every couple of weeks.

2. Turning the user feedback into new "stories" to go "on the backlog". This of course involves prioritising them.

You do this over and over, in short iterations, until you run out of time (you probably have time to do six to eight iterations). At the end of each iteration you have something to ship that is "better" (has more high-priority features, incorporates more feedback) than what you had at the end of the previous iteration. This is progress.

Each end-of-iteration release has two purposes: to show progress and make the user community a bit happier, of course, but also to elicit more feedback, to find out new information. Every version is both a solution and a probe. This dual nature continues after the first public release. A public release is a deep space probe that you send out into the solar system to send back pictures of strange new worlds (in the form of exception stack traces).

The whole thing is scientific and rational. You make decisions about order of work based on order of priority. You get constant feedback based on a working version of your product, instead of having to guess the feedback you'd receive from an imaginary version of your product.

People will respond to this approach by saying that it will be horribly "inefficient". Efficiency is a relative term. Projects that don't work this way always end up working this way in the end. But "in the end" is very late. Usually there's a mad panic for an extra N months after the original deadline, where the project keeps producing repeated versions of the product that are all "nearly right" or "nearly done", in a crazy self-deluded parody of iterative development.

Fortunately, you can start thinking and working this way at any time. Better to start halfway to the original deadline than shortly after it.