Code re-use when it's inappropriate
-
functionality in the GUI eh? Sounds like you should make a meeting and sort out your options - including a new schedule.
regards Torsten When I'm not working
TorstenH. wrote:
Sounds like you should make a meeting and sort out your options - including a new schedule.
5 - That's what I was going to suggest.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
-
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
Mine is the exact same story, it all began 5 months ago with just relabeling a few things and rebranding the system for the new users. Today its anything but the old system in terms of functionality and code larlegly, but i guess its all on me I decided to re-use the framework of the old system and butchered it anew based on the periodic reviews of the usage. The database has totally changed and so have the Silverlight frontend and ASP.NET admin section.
-
Mine is the exact same story, it all began 5 months ago with just relabeling a few things and rebranding the system for the new users. Today its anything but the old system in terms of functionality and code larlegly, but i guess its all on me I decided to re-use the framework of the old system and butchered it anew based on the periodic reviews of the usage. The database has totally changed and so have the Silverlight frontend and ASP.NET admin section.
That's pretty similar to my project, except the sales guy who was supposed to be selling the rebranded product with a few bells and whistles got ideas of grandeur, grabbed the ear of the MD and started making changes...
-
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
After spending some time on similar problems, my position is that "code reuse" is a purely technical matter rather than a business decision. It goes this way : - the specifications have to be expressed first, by the user (or product owner or client or whoever ...) ; he is able to add whatever constraints to the system, as long as they are external to the system (for example, he decides the interfaces of the system) - depending on what is needed, i see if and what available components can be reused ; these components can come from previous projects or from external sources (such as web, ...) - i write down an estimate of the total price, depending on what i know can be reused and what has to be created from scratch - the client is then able to accept my offer ; there is no bargain, and he has nothing to say about the technical decisions about the internals of the system - if he doesn't agree with my proposition, his freedom is to change the needs (or to find someone else to do the job) Any similarity with a big "planning game" would be normal :-) It works better on small increments (because some change will happen soon or later, and a small scope means smaller changes) That way, there is no such thing as "just take this and do that and that ..."
gzo
-
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
Sounds sooo much like my life right now! Except we completely lack any kind of functional specification for our projects. Our primary application is an industrial automation interface, and has been "evolving" for over 15 years, mostly in VB6 (*shudders* X| ). Last year we had one of our larger customers threaten to leave us if we didn't come up with a "new" interface software. So the decision was made to re-label the application, hide the features that the specific customer objected to, and add in some drastically new features in their place. Needless to say, this did not go over well with us underlings in the development team. But management and sales (and the customer) would not let us have the time we really need to re-evaluate the application, develop an actual functional specification, and rewrite the application is something more contemporary than VB6. So we're stuck forcing more kludges and quick-fixes on a bloated and fragile 15+ year pile of already huge technical-debt. So yeah, code re-use is not always appropriate. Unless it's a well-maintained generic library with flexible, compliant interfaces, most of the time I find myself wishing I was allowed to work from the ground up on things.
-
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
-
OOPs. ;P
No dogs or cats are in the classroom. My Mu[sic] My Films My Windows Programs, etc.
GenJerDan wrote:
OOPs. ;-P
As in "Oopsie" or "Object Oriented Programming"? The first doesn't need explanation, but the second...? I'm really bad at that, when I start a class, reuse isn't in my vocab., it's only later that I realize that I should have thought about it when I started the design. Then when I do think about it, its "How can I make this reusable when I can't think about how it can\should be changed?" For instance, I had this written testing question about testing a ShuffleCards routine that takes an array of Card objects. I set up a Card class that lets you use the standard 52 card deck values. Later, I realize this should work with PokerCard, TarotCard, and UnoCard as well. I set these cards up and I have verified the two arrays have the same number of cards, the same type of cards, and I'm about to verify they have identical cards when it hits me that I built this class to modify the card value with the identical card test in mind. I didn't build it with the idea of playing a game with it. I added an inheritable get property to return an Imutable bool value that returns false. The identical card test will fail if it returns true. And I just realized another test case just writing this out... Man, can you make testing a b..ch. (You know I meant "beach", right? Just like this prime beach front property for only $100. Wire me the money and I'd send you the deed later. :laugh: )
-
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
I've been in this situation before. Code re-use is often frustrating. I really dislike reinventing the wheel, but in situations like these it can be hard to tell whether it will be worth re-using the code. One thing to look at when deciding whether to reuse other code is the quality of it. Does it smell? Is it rigid or fragile? I find the answers to those questions are almost certainly a yes. It's very hard to find good quality code. In your situation, maybe it would have gone bad either way? If you write good code and the spec changes then it's going to be difficult.
-
I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:
i find that the question of reuse is really a question of granularity. its all well and nice to write fairly large classes with fairly large methods but the truth is these classes and these methods are brittle even in an OOP design. 3 tier architectures, design patterns, etc allow us to break apart large classes into reusable chunks by separating what already works into more thoughtful pieces (this is the place where business decisions get made) and into more functional pieces (this is where parameters are matched, this is where assemblies are created). so its not all the users fault here. sure they changed the functionality, but they always do. did you have a clear game plan on how to separate classes so that they did one thing and one thing only? did you make sure that each pattern did its job? (parameters were only handled by an adaptor, assemblies only handled by a facade?). i know you think you're too deep in the fire to go back to get the firetruck but i can tell you from lots of past experience each fix can be put in place by careful deliberate steps.
Paul Alagna