6 ms·

> That's exactly why this list is set up the way it is: you will get results fast and they will be good results. What do you mean by 'fast'? If you can get mea

> That's exactly why this list is set up the way it is: you will get results fast and they will be good results. What do you mean by 'fast'? If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. > If you want to play the 'I'm doing a sloppy job because I'm under pressure' card No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making.

jacquesm 9y ago
> What do you mean by 'fast'? Much faster than by going the rewrite route (assuming that is even possible, which I am convinced for anything but the most trivial problems it isn't). Preferably to first deploy within a few days and incremental changeover to the new situation starting within two weeks or so of the starting gun being fired. > If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. No. > If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. Who said so? All I said is that you should only do one thing at a time. Do not attempt to achieve two results with one release. > No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making. You are very welcome to your own opinion about my 'overly generalized suggestions' it's just that they are a lot more than suggestions, they are things that I (and others, see this thread for evidence) have used countless times and that simply work. All you do is a bunch of naysaying without offering up anything concrete as an alternative that would work better or evidence that anything posted would not work in practice. It does and it pays my bills.
- alexwebb2 9y ago
  > > What do you mean by 'fast'? > deploy within a few days and incremental changeover to the new situation starting within two weeks or so I'm going to take this as confirmation that you're working on very, very small projects. This would be an extraordinarily unrealistic timeframe for large projects, which take vastly larger quantities of time to apply the steps you've outlined - which, in turn, renders those steps useless in a competitive business context as far as large applications are concerned.
  - jacquesm 9y ago
    No, it just means that I have crew for jobs like these that knows their stuff. 500K lines is 'small' by our standards and if we are not moving within two weeks that translates into one very unhappy customer. That's something a typical team of 5 to 10 people has produced in a few years. Note that I wrote 'incremental' and 'starting'. That doesn't mean the job is finished at that point in time. But we should have a very solid grasp of the situation, which parts are bleeding the hardest and what needs to be done to begin to plug those holes. That the whole thing in the end can become a multi-year project is obvious, we're not miracle workers, merely hard workers. In a way the size of the codebase is not even relevant. What is most important is that you get the whole team and the management aligned behind a single purpose and then to follow through on that. Those first couple of weeks are crucial, they are tremendously hard work even for a seasoned team that has worked together on jobs like these several multiple times. The one case I wrote about here was roughly that size (so small by my standards), within 30 days the situation was under control. We're now two years later and they are still working on the project but what was done in that short period is the foundation they are still using today. If a project is much larger than that then obviously it will take more time. Just the discovery process can take a few weeks to months, but in that case I would recommend to split the project up into several smaller ones that can be operated on independently with 'frozen interfaces' where-ever they can be found. That way you can parallelize a good part of the effort without stepping on each others toes all the time. The problem is not that you can't tackle big IT projects well. The problem is that big IT projects translate into big budgets and that in turn attracts all kinds of overhead that does not contribute to the end result. If you strip away that overhead you can do a lot with a (relatively) small crew. If you're going to tackle a code base in excess of something 10 M loc in this way you will again run into all kinds of roadblocks. For those situations it would likely pay off to spend a few months on the plan of attack alone. If a project that large came my way I would refuse, it would tie us down for way too long. But that's out of scope for the article afaic, we're talking about medium to large project, say 50 manyears worth of original work that has become unmaintainable for some reason or other (mass walk-out, technical debt out of control or something to that effect). If those are 'very very small projects' by your standards than so be it.
    - 9y ago

jacquesm 9y ago

> What do you mean by 'fast'? Much faster than by going the rewrite route (assuming that is even possible, which I am convinced for anything but the most trivial problems it isn't). Preferably to first deploy within a few days and incremental changeover to the new situation starting within two weeks or so of the starting gun being fired. > If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. No. > If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. Who said so? All I said is that you should only do one thing at a time. Do not attempt to achieve two results with one release. > No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making. You are very welcome to your own opinion about my 'overly generalized suggestions' it's just that they are a lot more than suggestions, they are things that I (and others, see this thread for evidence) have used countless times and that simply work. All you do is a bunch of naysaying without offering up anything concrete as an alternative that would work better or evidence that anything posted would not work in practice. It does and it pays my bills.

alexwebb2 9y ago
> > What do you mean by 'fast'? > deploy within a few days and incremental changeover to the new situation starting within two weeks or so I'm going to take this as confirmation that you're working on very, very small projects. This would be an extraordinarily unrealistic timeframe for large projects, which take vastly larger quantities of time to apply the steps you've outlined - which, in turn, renders those steps useless in a competitive business context as far as large applications are concerned.
- jacquesm 9y ago
  No, it just means that I have crew for jobs like these that knows their stuff. 500K lines is 'small' by our standards and if we are not moving within two weeks that translates into one very unhappy customer. That's something a typical team of 5 to 10 people has produced in a few years. Note that I wrote 'incremental' and 'starting'. That doesn't mean the job is finished at that point in time. But we should have a very solid grasp of the situation, which parts are bleeding the hardest and what needs to be done to begin to plug those holes. That the whole thing in the end can become a multi-year project is obvious, we're not miracle workers, merely hard workers. In a way the size of the codebase is not even relevant. What is most important is that you get the whole team and the management aligned behind a single purpose and then to follow through on that. Those first couple of weeks are crucial, they are tremendously hard work even for a seasoned team that has worked together on jobs like these several multiple times. The one case I wrote about here was roughly that size (so small by my standards), within 30 days the situation was under control. We're now two years later and they are still working on the project but what was done in that short period is the foundation they are still using today. If a project is much larger than that then obviously it will take more time. Just the discovery process can take a few weeks to months, but in that case I would recommend to split the project up into several smaller ones that can be operated on independently with 'frozen interfaces' where-ever they can be found. That way you can parallelize a good part of the effort without stepping on each others toes all the time. The problem is not that you can't tackle big IT projects well. The problem is that big IT projects translate into big budgets and that in turn attracts all kinds of overhead that does not contribute to the end result. If you strip away that overhead you can do a lot with a (relatively) small crew. If you're going to tackle a code base in excess of something 10 M loc in this way you will again run into all kinds of roadblocks. For those situations it would likely pay off to spend a few months on the plan of attack alone. If a project that large came my way I would refuse, it would tie us down for way too long. But that's out of scope for the article afaic, we're talking about medium to large project, say 50 manyears worth of original work that has become unmaintainable for some reason or other (mass walk-out, technical debt out of control or something to that effect). If those are 'very very small projects' by your standards than so be it.
  - 9y ago