Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Don't “scrap the old and start over.” Don't even say in public that you might. I think you've chosen a solution without defining the problem here (or at least, you've got a specific solution to a very general problem). There are plenty of times where it's a good idea to scrap everything and start again. This can be from the technical end (e.g. the code base is barely maintainable, the design has fundamental flaws, the infrastructure is no good), or from the customer end (e.g. the system never worked properly, or did what we wanted it to do, the business has moved on, numerous "paradigm shifts" have occured). I agree, it's not a good idea to scrap everything without a good reason. But good reasons often crop up. And it's important that the "business" type people, who are often the ones who write the cheques, recoginise that this might not be something initiated by them. Just because something "works fine" now, doesn't mean it's economical to leave as is, when every minor change takes weeks to complete. More generally, I think Agile can offer a lot of help in most of these issues. I prefer Scrum with XP-style development practices. A lot of people still baulk at the mere term "Agile", but a lot of that is because it's been adopted as a buzz word, and completely mis-interpreted. Even if you do understand the theory side, putting it into practice can be a lot harder than you might think, especially in large organisations, with a lot of "baggage" entrenched in both processes, and people's expecatations. (Hint: to put it into place in this sort of environment, you almost *have* to have an independant Agile Coach. You'll probably find that as soon as you start trying to remove impediments, you'll find huge webs of resistance from upper management that are difficult to break down yourself). I think what people who've put Scrum in to practice well find, is that if they really want to produce working software on a regular basis, they have to address how the entire organisation operates. To me, that's a reflection on the fact that software has become so integral to so many business, and is much more complex than your average (non-development) project. Bottom line is: getting it right is hard. And we're still learning how to do it. As a side note, it probably goes without saying, but there is only so much you can learn out of books. Experience is crucial, including learning from others' experience. In reply to Re: Musings: Why do well-intentioned projects go so wrong, so often?
by Mutant
|
|