Duplication vs. Complexity
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
I don't know how it fits in your dev environment, but I've had success with a hybrid approach. Basically a couple of large include files that do all the scaffolding, UI layout etc. Each form includes them, calls the setup routines with appropriate page titles, etc. Then has its own logic to handle the fields specific to that form. So, basically, abstracting into (one or more) separate files, the stuff that is common to all the forms. hth Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
Depends on your stack, requirements, etc but in something like Angular, component composition would be a good solution to this problem. The idea being you have each of the specific components for the request types that deal with their specific stuff, and they include the common component in their template to handle common stuff, communicating with it through
@Inputand@Outputbindings. Of course this assumes the common component is actually common. If it just so happens that it's common right now then it's not really common and I'd go with duplication instead. Otherwise that common component will end up accruing so much special-behavior-spaghetti over time it'll become unmanageable. Those are my initial thoughts at 5am at least. Reader beware :laugh: -
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
I have a situation sounds almost the same. About 50 fill-in forms that has 80% common and 20% special... I have this also in ASP.NET and also Angular... I solved it using inheritance - a base form holds 80% of the code (part of which depends on settings overwritten by derivates(?))... And 50 derivates to add the case specifics...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
Without knowing all the details, it seems I have to point the obvious: do whatever is easier for the user. Don’t let him wade through a long, complicated form just because it makes your code nicer. In the end, users’ time is more valuable than yours (at least because there are so many of them) and making them happy should be the most important thing. Without them your company would not survive and you’d be looking for a job.
Mircea
-
Without knowing all the details, it seems I have to point the obvious: do whatever is easier for the user. Don’t let him wade through a long, complicated form just because it makes your code nicer. In the end, users’ time is more valuable than yours (at least because there are so many of them) and making them happy should be the most important thing. Without them your company would not survive and you’d be looking for a job.
Mircea
-
Without knowing all the details, it seems I have to point the obvious: do whatever is easier for the user. Don’t let him wade through a long, complicated form just because it makes your code nicer. In the end, users’ time is more valuable than yours (at least because there are so many of them) and making them happy should be the most important thing. Without them your company would not survive and you’d be looking for a job.
Mircea
Mircea Neacsu wrote:
making them happy should be the most important thing
Except that sometime the most desired thing is to wipe them out totally :mad:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Mircea Neacsu wrote:
making them happy should be the most important thing
Except that sometime the most desired thing is to wipe them out totally :mad:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
:laugh: Sure, but don’t we have the same love/hate relationship with many in our own families. Seriously speaking, I’m a passionate advocate for a user centric point of view. I’ve seen too many programmers and ‘architects’ in their ivory tower looking with disdain to lowly users and forgetting our whole profession come in existence just to help these users. Can you imagine the people at MIT programming the Apollo guidance computer and saying “screw these astronauts, they are just some trained monkeys”?
Mircea
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
see yourself in 1 year, what kind of psychopath will you be when you'll have to do changes in that code. Refactor your code.
CI/CD = Continuous Impediment/Continuous Despair
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
I've successfully used a single dialog with all content and then injected the display and validation logic from a container. It should give you the best of both worlds.
veni bibi saltavi
-
see yourself in 1 year, what kind of psychopath will you be when you'll have to do changes in that code. Refactor your code.
CI/CD = Continuous Impediment/Continuous Despair
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
Complexity is perhaps going to make it easier to extend. Duplication will in all likelihood make it easier to debug. I know it's the wrong answer from a software engineering point of view - but from the point of view of someone who spends a lot of time fixing defects on a huge code base I would go for duplication. I have seen a lot of code that makes use of inheritance and quite frankly I have found it to at times be something of a nightmare. Complexity is clever and is elegant but it can make tracking and fixing bugs a lot more difficult.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
Inheritance and specialization. Maybe make the common sections into UserControls, etc.
-
Mircea Neacsu wrote:
making them happy should be the most important thing
Except that sometime the most desired thing is to wipe them out totally :mad:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Be careful what you wish for - we are all users, occasionally...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Complexity is perhaps going to make it easier to extend. Duplication will in all likelihood make it easier to debug. I know it's the wrong answer from a software engineering point of view - but from the point of view of someone who spends a lot of time fixing defects on a huge code base I would go for duplication. I have seen a lot of code that makes use of inheritance and quite frankly I have found it to at times be something of a nightmare. Complexity is clever and is elegant but it can make tracking and fixing bugs a lot more difficult.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I've successfully used a single dialog with all content and then injected the display and validation logic from a container. It should give you the best of both worlds.
veni bibi saltavi
Welcome Back Mr. Vilmos. ;) Long without seeing you. I hope everything is fine with you and your people.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
GuyThiebaut wrote:
Complexity is clever and is elegant but it can make tracking and fixing bugs a lot more difficult.
Yeah, that's what I'm hoping to avoid.
That's when you're overdoing it. Put everything common in a base file that you inherit. Duplicate the rest.
Wrong is evil and must be defeated. - Jeff Ello
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
A bit of a different idea: could you implement the common code in UserControls and classes so they have a well defined internal API?
-
GuyThiebaut wrote:
Complexity is clever and is elegant but it can make tracking and fixing bugs a lot more difficult.
Yeah, that's what I'm hoping to avoid.
I would also favour composition over inheritance where possible. So you could have a baseclass form that is very basic, then the implemented forms can perhaps use some form of builder to class to individually tailor those forms. Using composition may make it easier to see what each form is built from.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
A bit of a different idea: could you implement the common code in UserControls and classes so they have a well defined internal API?
Hmm, metal note: refresh the page and read any new posts before posting. PIEBALDconsult beat me to this by about 2 hours and 30 minutes.
-
Rubber ducking here... ;) I'm working on a project that has a form which the user must fill in to submit a request. This form is used for various request types (+- 4) and shares common functionality (about 70%) between them. I have the choice of duplicating the form (UI and probably Logic) for the various request types or having one form with sections and columns that will be shown or hidden based on the request type. Either approach has pros and cons... Duplication: More maintenance if the common sections / logic change. Each request type's form will need to be updated. Complexity: Potentially many if else statements and more complex to understand and maintain e.g. changes in the common sections could break it for multiple request types. Which approach would you use? Maybe there is a hybrid approach? Edit: This is an Angular project, but I think the question applies to development in general.
Every time I've re-used UI for multiple forms I've come to regret it. Ask yourself, who are the stakeholders for every form? Are they the same? Do they know if another form is changed? Do all forms change at the same time? If any of your answers is "no" then duplicate them, they look the same (for now), but are functionally different. I didn't and am now in a situation where one form is evolving while the other isn't and the amount of if-else's is too damn high! :sigh: Now, I only re-use specific elements or components on a page. Talking web (ASP.NET MVC and Razor Pages) and WinForms experience here (maybe your hybrid approach?).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
