Programming insanity, or am I just missing the point.
-
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:
-
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:
I think the hallmark of a good hack job is that on the surface, it doesn't look like a hack. I've whipped up small apps that from the high level view look structual sound, and on the inside have all kinds of nasty and inefficient string splicing because it's the easier thing to do. As for patterns, i like them, they have a purpose. Infact, i used them even before i knew what they were, so i only really trust design patterns i figured out before i got the GOF book. I do have a gripe that writing more code than the bare minimum is "Overengineering", when infact, the bare minimum is gross underengineering. Reminds me of a saying i saw somewhere: "Just good enough is rarely enough, and never good." There IS a happy medium. T
------------------------------- Carrier Bags - 21st Century Tumbleweed.