Best programming methodology for very fast timeline and little requirements?

Question

What is a good programming methodology for custom applications that need to be coded very fast and very customized? I realize the lack of requirements is a problem no matter what. Also how do you convince management to change their practices? Next question is how to you get people to stop writing 5000 line single file programs?

Answer 1

run... like hell

Answer 2

Scrum is good to use on these kinds of projects. It is great at providing a way of persuading management that you can have the project on time or you can have it with all the features you want, but you can't have both.

Answer 3

Use the Force.

But seriously, this sounds like a Death March. Run away.

Answer 4

Scrum would be my guess to but keep in mind that scrum requires very disciplined team members. Get in the habit of documenting what requirements you do get and keep them in a place so that everyone, including management, can access it. Finally, find a reasonable way of forecasting tasks and keep that in front of management so that they know the current priorities of everyone on the team. I've been in a very similar environment for the last year and unfortunately I have not discovered a magic bullet.

Writing 5000 line programs is a sign of sheer laziness. We recently let a guy go because first he started with 5000 line Java classes then he moved into using try/catch statements to initialize variables in a constructor (don't ask). Find a way to motivate the guy writing the 5000 line programs with some constructive criticism. It sounds like it's a management issue at the heart of it however.

Answer 5

The fastest possible way to do anything resembling reasonable custom development is with you and the customer developing it together. The feedback is instant, and they can see exactly what is involved. Otherwise, you are just trading speed for their more convenient attention. Also, since they worked directly with you, they may defend you to your management.

However, without further context, I have to agree with the others and say it's probably not the most career-building situation.

Answer 6

If "lack of requirements" is really the fact, then you should NOT even start a project. I believe what you mean is "unclear or uncertain of requirements". If this is your case, then Agile Process is what you should consider. XP, Scrum or Crystal. Scrum is undoubtedly the most light-weighted agile process.

Management may have different mind from engineers, but you cannot say that management is wrong and their practices should be changed. Just communicate more to improve understanding and address conflicts.

To prevent people to write unreadable code, the best way to train people to write code in concise way. Pair programming and continuous code review might be a good solution.

Answer 7

As a general rule you have three components of a project, Time, Quality and Money.

It looks like your customer/boss wants to control the Time ... and he should get to control one more, the other you get to control.

So if he wants to control Time and Quality he needs to pay you and/or your team more money for all the extra time you are going to put in. If he wants to control Time and Money, you get to control the Quality, which in this case will be low.

What we always tell our customers is that they can have it Right or they can have it Now, but they CANNOT have it Right Now!

I don't think the methodology matters much ... the real issue is the timing.

Answer 8

Nothing new here!

What I found to work very well is a RAD technique called Evolutionary Prototyping.

The best approach is to implement your idea of what the customer wants, then present it to him, get his comments and adapt your implementation accordingly. When the customer is eventually satisfied, your implentation is done. Now comes the fun part: document it!

Answer 9

Scrum or XP works pretty well in these circumstances; if you can thrash out some minimal set of requirements for a "basic" system and build upon that, you can be reactive to the fact that even when up-front requirements are provided, they are almost always wrong.

People who write 5000 line single file programs are undisciplined and bad programmers. Since both XP and Scrum require the discipline to make a system that can be maintained and built upon, I'm not sure how to proceed if that's what you've got to work with. My guess would be to at least attempt to convince them the wrongness of their ways.

Answer 10

I don't meant to be cheeky but it seems like most people have gotten confused with the answer you are after. Most of the answers seem to be around project management methedologies rather than programming methods.

Given your situation i think SCRUM and agile type methods (like Open UP) would work fine from the project management approach. In fact i would stick with just SCRUM as it doesn't sound like there is much in the way of structure around your project. It will keep things nice and lean and should focus attention on the tasks at hand. You just need to make sure that you follow some basic rules of SCRUM which are to identify your tasks, estimate your tasks, describe your tasks, plan your iterations and if at all possible perform a sprint retrospective. If you are really tight on time then i'm sure you could drop this.

To answer your actual question (as i see it anyway), i would suggest you adopt a domain driven approach using CRC (Class Responsibiltiy Collaborator)cards as your design mechanism. I'm assuming that your application has some limited domain that it exists in, i.e. accounting, stock management etc. Try to decompose your domain into the objects that exist in the domain i.e. the real world objects like "stock item", "invoice", "delivery" etc. Then for each of these objects create a CRC card where you define its name, its responsibilities and other classes that it collaborates with to perform its responsibilties. You then write actual classes to represent these CRC cards in your application.

Avoid creating any class with a Manager suffix, or cooridinator or anything along those lines. What you should end up with is a set of objects representing the domain which you can easily modify with out needing massive refactoring to perform any kind of activity that happens in that domain. You can easily adapt a solution built like this with changing requirements as the domain objects should remain static unless you are adding more objects or your domain broadens.

Hope this is of use to you.

Answer 11

Ok Scrum looks interesting...can it be implemented when offices are in different locations?

Answer 12

There's more than one question that you ask.

1. fast development with 'little' requirements => hacking using scripting language, assuming there are small or few requirements, as opposed to there are no stable or explicit requirements yet but there will be tons in the future
2. fast development with tons of unstable, or implicit requirements => scrum, XP, etc. Focus on prototyping to get feedback from your customer about what he wants as soon as possible
3. Get management to change their practices => Let the project crash as soon as possible ;-) Seriously, this requires you to be more specific on what you want to change. Your mileage depends of course on how dilbert-like your environment is, and how cynical you are about really achieving your goals.
4. Getting people to stop writing 5K lines programs in a single file => Show them in what way it is a problem for you, how it would be equally easy to write better structured programs, show the benefit that they might have from it as well, and try to agree mutually on a better practice.