Programming insanity, or am I just missing the point.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
and not via (his view) of design patterns
this is one of the key points. Design patterns are more than just widdling a square peg to fit into a round hole! It's not about forcing the round hole, it is about finding the right pattern for the activity. I have pressed my team to use design patterns where they fit and are easily recognizable, and to at least consider what patterns match each subject as they are designing things. I have also reminded them that some patterns have similar purposes, and caution should be considered to find the right fit. In the GoF book they compare design patterns with architecture, in fact code architecture is definitely a good concept; but it is also pointed out that physical architecture has inter-use concepts, but not the same exact use. You don't want a wooden door on a shower stall, and yet the function is the same as a bathroom door. Conversely you generally don't want a glass door on the bathroom door, but it is quite acceptable on a shower stall. The function is similar, but the purpose is not. Design should never be forced. In fact, in the GoF book as well as Agile programming, Code Complete, and others, there are comments about detecting poor design by detecting poor fit for use. A design should fit comfortably for the purpose it was intended. It sounds like your design fit, his did not. I've had the discussion with someone else before and it ends in a stale-mate, but I will say it again, a design is not a superior design unless it considers performance. Balanced designs consider maintenance, creation, and run-time. If a design considers only the first 2 without even the slightest regard to the 3rd, then it is a 2 legged stool, and they are very hard to sit on properly.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns.
Reminds me of a joke: how many design patterns a Java programmer needs to write a "Hello world" app?
-
He sounds like an idiot.
BW
Quick to judge, quick to anger, slow to understand.
Ignorance and prejudice and fear walk hand in hand.
-- Neil Peartbrianwelsch wrote:
He sounds like an idiot.
He is an idiot. :-)
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten.
Another glaring example of the inablity of many in project leadership roles to seperate their perception from their ego. It is sad how often a good project spirals south because a manager dismisses anything that contradicts what he/she "feels" should be the "right way".
"We are all repositories for genetically-encoded information that we're all spreading back and forth amongst each other, all the time. We're just lousy with information." - Neal Stephenson
-
When I hear the phrase "Software Architect", I reach for my revolver headphones. i was thinking about this last night, in fact... i have an app that's grown organically over the past 9 years - features are bolted-on as they are needed, things are wedged-in here and there, etc., it's a beast - but people like it. now, there are some changes i'd like to make to it, to make it more useful for end users. but i don't see any way to make those changes without a near-total rewrite, which is something i'm just not up for. so i sighed and thought to myself "if only i'd sat down, nine years ago, and designed this thing in a Software Architect-approved Manner, using UML and state diagrams and use-cases and layers of abstract classes and clever messaging paradigms! it'd be so easy to make it do these things that it was never designed to do in the first place!" wait... what? of course it wouldn't!! even the best design is only fit to handle the problem as stated at the time - you can abstract it and try to make things flexible and modular, etc. but that's still just extending the design to things you anticipate, and you can't anticipate everything. and nobody can design for the things that will be demanded a decade later. for example, this is an imaging application, and there's no way i could've foreseen, in 1998, how widespread, cheap and popular digital cameras would become in 2007, or how things like Flickr would change how the pictures from those cameras end up on the web. i could've written it using the cutting-edge design and programming tools of 1998 and what would i have... a mess of ATL objects using DCOM? whatever. it still wouldn't help me solve the problem of making an app that was designed to do one thing well do something very different. you design as much as you need to, to get the job done in the time you have. anything else is jerking off. /rant
image processing toolkits | batch image processing | blogging
To be perfectly honest, you would probably make a very good software architect (the sane and smart type, not the stupid type). Software architects can do a lot of good as long as they are realists, pragmatic and keep the clear vision that the job they hold is to make the job of the other programmers as EASY as possible so they in turn can deliver a top notch product quickly to the end users.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
ednrgc wrote:
On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns.
Reminds me of a joke: how many design patterns a Java programmer needs to write a "Hello world" app?
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
He should have suggested a book Refactoring To Patterns[^] to you :) Caution: Java inside
Regards, Â Zdenek
Nothing is as persistent as a temporary solution (a lesson learned from my experience)
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
In my opinion: no, you have not missed the point. However, even when I create a mock-up I give it some kind of thought and design it in a way that it is possible to expand it later and/or reuse the code. Regarding software architechts I have experienced both good and bad. Of course there's a need for a software architect, but he/she had better be a good one. ;) Sometimes when a professional craftsman reasons like the one you're describing, I wonder if they are insecure and want technologies and/or buzzwords that are known to be a good thing by the management. In that way if something goes wrong anyone would be "safe" to blame those technologies/buzzwords. I also think James has a point in his "child with a hammer" analogy. It's a common phenomenon when someone has been attending a course or education where they suddenly had an epiphany; they come back with the child-with-a-hammer syndrome.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects.
Functions without side-effects. Alas, many programmers seem unaware of this concept and the advantages thereof.
ednrgc wrote:
I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns.
The way I look at Design Patterns with regards to "black box" programming is that it describes various ways for the black boxes to interact in a seamless fashion through the use of polymorphism. It's what object oriented programming should be about: Dependency Management. However, they should be used sparingly. They appeal to kid in us that loved sitting down with a box of Legos[^] and building all kinds of monstrosities.
ednrgc wrote:
We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten.
My advice would be to beat him at his own game. Get a copy of Design Patterns[^], if you don't already own one. Become familiar with all of the pat
-
When I hear the phrase "Software Architect", I reach for my revolver headphones. i was thinking about this last night, in fact... i have an app that's grown organically over the past 9 years - features are bolted-on as they are needed, things are wedged-in here and there, etc., it's a beast - but people like it. now, there are some changes i'd like to make to it, to make it more useful for end users. but i don't see any way to make those changes without a near-total rewrite, which is something i'm just not up for. so i sighed and thought to myself "if only i'd sat down, nine years ago, and designed this thing in a Software Architect-approved Manner, using UML and state diagrams and use-cases and layers of abstract classes and clever messaging paradigms! it'd be so easy to make it do these things that it was never designed to do in the first place!" wait... what? of course it wouldn't!! even the best design is only fit to handle the problem as stated at the time - you can abstract it and try to make things flexible and modular, etc. but that's still just extending the design to things you anticipate, and you can't anticipate everything. and nobody can design for the things that will be demanded a decade later. for example, this is an imaging application, and there's no way i could've foreseen, in 1998, how widespread, cheap and popular digital cameras would become in 2007, or how things like Flickr would change how the pictures from those cameras end up on the web. i could've written it using the cutting-edge design and programming tools of 1998 and what would i have... a mess of ATL objects using DCOM? whatever. it still wouldn't help me solve the problem of making an app that was designed to do one thing well do something very different. you design as much as you need to, to get the job done in the time you have. anything else is jerking off. /rant
image processing toolkits | batch image processing | blogging
-
ednrgc wrote:
I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects.
Functions without side-effects. Alas, many programmers seem unaware of this concept and the advantages thereof.
ednrgc wrote:
I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns.
The way I look at Design Patterns with regards to "black box" programming is that it describes various ways for the black boxes to interact in a seamless fashion through the use of polymorphism. It's what object oriented programming should be about: Dependency Management. However, they should be used sparingly. They appeal to kid in us that loved sitting down with a box of Legos[^] and building all kinds of monstrosities.
ednrgc wrote:
We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten.
My advice would be to beat him at his own game. Get a copy of Design Patterns[^], if you don't already own one. Become familiar with all of the pat
Leslie Sanford wrote:
Functions without side-effects. Alas, many programmers seem unaware of this concept and the advantages thereof.
'5' for that alone. :cool:
Leslie Sanford wrote:
next time say something like, "See? This is an interesting application of the Strategy pattern. It can be plugged into other apps easily. If we need a different approach, we can always write a different Strategy."
At which point they get into a long argument about what "design patterns" means to me... ;P
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
I think reuse is WAYYYYYY less important than the code working. And working as simply as possible. I don't think the GOF should be shot. But the dorks who insist on classes with "factory" and "builder" -in- the class name... Well, they should be shot. Let's keep it simple...
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
Wow... I've often found the principle "simple is better" works really well... or, perhaps better stated - "Make thinks only as complicated as they need to be to do what they're supposed to do". I agree with you - design patterns have their place. Simplicity also has its place.
-
When I hear the phrase "Software Architect", I reach for my revolver headphones. i was thinking about this last night, in fact... i have an app that's grown organically over the past 9 years - features are bolted-on as they are needed, things are wedged-in here and there, etc., it's a beast - but people like it. now, there are some changes i'd like to make to it, to make it more useful for end users. but i don't see any way to make those changes without a near-total rewrite, which is something i'm just not up for. so i sighed and thought to myself "if only i'd sat down, nine years ago, and designed this thing in a Software Architect-approved Manner, using UML and state diagrams and use-cases and layers of abstract classes and clever messaging paradigms! it'd be so easy to make it do these things that it was never designed to do in the first place!" wait... what? of course it wouldn't!! even the best design is only fit to handle the problem as stated at the time - you can abstract it and try to make things flexible and modular, etc. but that's still just extending the design to things you anticipate, and you can't anticipate everything. and nobody can design for the things that will be demanded a decade later. for example, this is an imaging application, and there's no way i could've foreseen, in 1998, how widespread, cheap and popular digital cameras would become in 2007, or how things like Flickr would change how the pictures from those cameras end up on the web. i could've written it using the cutting-edge design and programming tools of 1998 and what would i have... a mess of ATL objects using DCOM? whatever. it still wouldn't help me solve the problem of making an app that was designed to do one thing well do something very different. you design as much as you need to, to get the job done in the time you have. anything else is jerking off. /rant
image processing toolkits | batch image processing | blogging
As long as it's not taken to extremes I agree, but I think your post might be mis-perceived by some. I had an app that grew organically over many years, exactly what you describe, but it was a beast of spagetti code as a result. We took the road you didn't and completely rewrote it from scratch (was MFC, we rewrote as .net) stratifying it into a data access layer, a business object layer, ui layer etc etc. Also modularized it as we should have done originally. It took about 2 years to rewrite the previous 5 years of development into a new program with many more features that had been requested for some time but were too hard to add to the original code. Now, going forward it's very easy to debug, very easy to add new features to etc. I was able to add an asp.net UI layer in a matter of months. However I would not go so far as to rigidly stick to a design pattern for everything, that's just not practical in the real world and the original posters boss is clearly an idiot or on a government payroll. I agree that you can't plan for every eventuality and the app you make now will require changes later on that you had not anticipated at all, which is precisely why it's worth it to start with a stratified, modularized design from the start with the mind set that it *will* need to be changed in future and should be designed from the start to be as accomodating to unforseen circumstances as possible. I don't recommend anyone writing an app these days without including as a fundamental part of the design the idea that they will be changing or adding to it in the future. Anyone who doesn't plan for change at first will ultimately do so on later projects when they get bit in the ass enough times.
"110%" - it's the new 70%
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
...Design Patterns.
Which are?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
Have had similar problems with a semi technical manager who loved MS related buzz words - ended up spending increasing what should have been a 3-6 month project to 2 years, only to find that the end project ran so slowly that it was unusable... The original prototype (coded in 2 months without web services, design patterns, etc) worked fine though so we extended that. Needless to say the manager got fired for that one.
-
Have had similar problems with a semi technical manager who loved MS related buzz words - ended up spending increasing what should have been a 3-6 month project to 2 years, only to find that the end project ran so slowly that it was unusable... The original prototype (coded in 2 months without web services, design patterns, etc) worked fine though so we extended that. Needless to say the manager got fired for that one.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
I'm in an interesting situation because, where i work, code is thrown together. I have no objection to quick and dirty apps, but i like them to be neat. However i am regularly accused of wanting to over engineer things, where i simply see it would be a better and scalable option over what we have. My primary concern is that, there are 5 different core applications all using 3 databases, and communicate with various other applications via proxy sites. Sql is written inline on a case by case basis (DB Changes - Things break), and many of what should be common classes are actualy just functions amalgamated into a huge 7000 line function class. My proposal was to move the Sql into a database API Library, create some relevant function classes to break down the HUGE function list, and use automated seiralization for communciation between the proxies. All of which got me dubbed as a design evangelist. I completely agree with your post. T
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
I think you boss has invented a Design Pattern Antipattern[^]. :)
-
I'm in an interesting situation because, where i work, code is thrown together. I have no objection to quick and dirty apps, but i like them to be neat. However i am regularly accused of wanting to over engineer things, where i simply see it would be a better and scalable option over what we have. My primary concern is that, there are 5 different core applications all using 3 databases, and communicate with various other applications via proxy sites. Sql is written inline on a case by case basis (DB Changes - Things break), and many of what should be common classes are actualy just functions amalgamated into a huge 7000 line function class. My proposal was to move the Sql into a database API Library, create some relevant function classes to break down the HUGE function list, and use automated seiralization for communciation between the proxies. All of which got me dubbed as a design evangelist. I completely agree with your post. T
------------------------------- Carrier Bags - 21st Century Tumbleweed.
I agree with your assessment. I always create a separate data layer, and usually a facade layer that eliminates changing anything in the UI layer. I NEVER use inline SQL statements for the reason you mentioned. I actually created my standalone "black-box" version with a data layer. But, since it didn't conform to his methodology, it was called a "Beginning ASP.NET version." :confused: