wood burning stoves*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Duct Tape design pattern - just boasting my newest discovery..... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Duct Tape design pattern - just boasting my newest discovery....." Watch "Duct Tape design pattern - just boasting my newest discovery....." New topic
Author

Duct Tape design pattern - just boasting my newest discovery.....

Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040

Duct Tape Design Pattern:

Architecture that creates a one-off solution using the path of least resistance.


I hate this inherited legacy....

- m
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Madhav, do you have a story to tell?


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040
Well......

I hate these one-off solutions. I hate it when someone says -
"lets give them a one-off solution and later extend it
to be a generic solution ". It never happens!!!

Since I have been hearing such things quite so often, I soon
recognized this as a Design Pattern and baptised it
as the title of this post reads.

And I also made it my new sig.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I have this pattern. In my experience it starts with the words "this is only a prototype", which then of course gets into production, needs to be patched here a little bit, there a little bit - and after one weak you have a nice little legacy app... :roll:

Actually our team has now coined the "no prototype principle" - we just refuse to believe that there is such a thing; if it is worth doing, it's worth doing it so that you can build on it.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
If those really are one-off solutions then what's the problem?

As long as that one-off solution is maintainable and satisfies today's requirements, wouldn't you be worse off spending more time and resources to building a fancier solution that eventually doesn't provide any more value to its user?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Maxim Katcharov
Ranch Hand

Joined: Sep 07, 2004
Posts: 113
Is there an example of a project that has no room for future enhancement?

I think that if you build something, there is always a chance that it will need improvement. If there is a very limited chance, then sure, don't take it. Personally, I'd refuse to build something like that for as long as I could... realizing you're doing something wrong may be the definition of learning, but continuing to do it is the opposite.

Usually though, you want to be able to reuse (no, not drop in, but edit parts of, or use what you've learned during) projects you've completed. Sure, you can build a project that should be scrapped because rebuilding it from scratch will be faster than learning it, but in that case, it may be better to learn to make it understandable.
Maxim Katcharov
Ranch Hand

Joined: Sep 07, 2004
Posts: 113
By the way, if there isn't one out there for this already, this would make a good legitimate anti-pattern as opposed to a tongue-in-cheek pattern. Could have sworn I've seen it somewhere though... this all sounds realllly familiar...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
If those really are one-off solutions then what's the problem?


I am not sure what is meant by a "one-off solution", but here are two examples from my experience:

ONE:

"We need to show the customer that it's possible to do this web form, so please prototype it. Just hardcode some html and a simple servlet..."

"The prototype was really good! Actually so good that he decided to use it in production until the real system gets installed. Oh, and he needs this second form immediately, too (they already had a press release about it). Don't invest much time, just copy the other one and apply those small adjustments..."

Four weeks later, we had 12 (twelve!) more forms hacked together this way.

TWO: (other company, actually)

"We need a prototype web access to our system. Just a simple servlet to show that it's possible."

"OK, the customer finally decided that we should build a fancy web frontend. By the way, they are already using the prototype in production and hardcoded the URLs in thousands of HTML pages - so they would kill us if we changed that..."
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
About four years ago we built a PowerBuilder application. The first try used a consulting outfit to provide an elaborate framework. It reached production but was unusable for the long term, so we ripped it out and went for a minimal framework. We made compromises and told managaement it would not survive through all the different user groups that were lined up for future use. Management promised we could throw it away in two years.

Well, three years later we started on a replacement with a vendor package in Java and Forte 4GL. We got some user groups into production, but we didn't quite sunset the PowerBuilder app before Forte 4GL and the version of the JDK and the Visual Age tools all went out of support. So we bought the vendor's upgrade to J2EE and got another group into production. So now we have three production platforms. One 1-off throw away that never went away, one enterprise-ready platform that died from external causes, and the new one. The plan is to sunset both PowerBuilder and Forte in short order.

Ya know, if you're going to replatform every two years, duct tape might do the job.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040
Ilja,

My posting is based on scenario 'ONE' you mentioned.
The "make-it-work" concept. Sky-is-falling, just for this
one time, harcode whatever, yeah yeah yeah I understand
all the limitations (you geeks), just make it work.
And now that it works, its a commercial product.

Lasse,

As long as that one-off solution is maintainable and satisfies today's requirements

Two comments here -

a. 'today' is always new and different than yesterday.
b. 'requirements' change.



Stan,

I agree with your thoughts. But the strong assumption in your
theory is that you replatform every two years.
When it comes to products which manipulate corporate databases,
every two years is an extremely costly affair - migrating
the databases to a new data model I mean. So, in the cases where
this design pattern applies, the life is much larger. Hence, I
beg to differ with the duct-tape design.

Thanks.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi all,

I thought I was the only developer stuck in pretty much mess

Looking at the people posting messages here, its scary to me because you people have very good approach for design/development and if you have been facing these issues I can't dare describe mine.

Why we should let that happen? If we are in consulting business its possible as consulting somehow is seen as "magical force" to do quick things but for bigger projects it can be simply "disasterous", cant it? And what I see is- software management has to be more mature because anyways otherwise clients end up receiving product that makes support people scream almost all time...Overall it costs more...

Anyways, I just emptied my hard feelings to people who understands

Regards,
Maulin
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Maulin Vasavada:
software management has to be more mature


I don't think it's only management which has to mature. After all, management typically is far too disconnected from the actual development job to accurately assess the tradeoffs.

Instead, we as professional software developers need to learn how to more effectively communicate the tradeoffs to management, and to make decisions of our own and stand to them.

Many of the above problems do not only happen because management tells us that the code won't need to be maintained, but as much because *we* act as if it were actually true. If we just used the same resources to work as if we had to maintain the code we write until the end of our life, we would already be in a much better position, in my experience.
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
In my experience, most of the 'quick-prototypes' and 'utility classes to do something simple for a short period of time' tend to have a life longer than the product they are supposed to help or evolve as a product by themselves.

The posts in this thread seem to validate this experience.

Given that, rather than classifying them as 'one-off' or 'dirty-prototypes', I would think that the best approach to take would be to treat them as a product and give them the respect that a product deserves.

1. Maintain the source code using a version control system
2. Write test cases. This, to my knowledge, is what is being emphasized by Agile methodologies and TDD. First do whatever works. Second, make minimal changes to accommodate the new feature and refactor out some common pieces, and Third, refactor further when adding the third new feature and make it into a product.

This 'three-box' principle is also the basis for designing frameworks. A framework, for example, cannot be created from scratch. It, in fact, evolves by experience. I think, Fayad, in his book, mentions this principle.

So, instead of thinking of these systems as one-off solutions, treat them as proper products and release them. That way, you will have a better control of what you are releasing and also be better prepared for future requests.


Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
BTW, if you need to do a Swing prototype, you might want to use the Napkin Look'n'Feel for it
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Originally posted by Ilja Preuss:
BTW, if you need to do a Swing prototype, you might want to use the Napkin Look'n'Feel for it


That look and feel could revolutionize software development.
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379

Now for that "three-box principle"...ummmmm...
You see, each refactoring takes time. That time needs to be added
to the project plan. That's where things go bad. When you mention
a new feature takes 10 days + I need 3 additional days to refactor,
then you never get those 3 additional days. Ever heard the phrase
"the deadline was yestrerday, but the requirement came in today!".


I understand the sentiment. This is typically the disconnect between the importance a manager gives to refactoring as opposed to the importance a developer gives to the same.

In such cases, I would like to quote Martin Fowler from his "Refactoring" book:


Of course, many people say they are driven by quality but are more driven by schedule. In these cases, I give my more controversial advice: Don't tell!

Subversive? I don't think so. Software developers are professionals. Our job is to build effective software as rapidly as we can. my experience is that refactoring is a big aid to building software quickly. If I need to refactor first and the design does not suit the change, I find it's quicker to refactor first and then add the function. If I need to fix a bug, I need to understand how the software works - and I find refactoring is the fastest way to do this. A schedule-driven manager wants me to do things the fastest way I can; how I do it is my business. The fastest way is to refactor; therefore I refactor.

- Martin Fowler from "Refactoring" book. Pg. 61


Given the advancements in IDE support for refactoring, I think refactoring is becoming more and more commonplace and hence shouldn't be a problem. If u are that concerned about the dates, just add 2 days to the 10 and tell your manager that you need 12 days to do the job.
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040
Sathya,

If I were calling the shots, it would be different around here
(and I wouldn't be staying late into the night and browsing
monster.com every night).

BTW, I also read a lot of (well, some) books about Software Design.
And having had that knowledge, I go back to my first post and question -
Why the hell, was this code written this way?

Now re IDE comment, are assuming that the software is written in Java ?
I agree, if its written in Java, its much easier to 'refactor', but then
there are those other languages!

Please don't get me wrong, I don't necessarily disagree with you, but just that some of the practical aspects of software design always tend to force some developers to override (either because of ignorance or otherwise) the age old principles of software design and architecture.

Hope you see my point.
Thanks.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Madhav Lakkapragada:
You see, each refactoring takes time. That time needs to be added
to the project plan.


I am far from convinced that this is true. Why doesn't refactoring let you go faster?


When you mention
a new feature takes 10 days + I need 3 additional days to refactor,
then you never get those 3 additional days.


Then don't do that.

First, this sounds a little bit like you want to use the *last* three days to refactor? Refactoring should be an ongoing activity, the first refactoring done one minute after you started coding.

Second, if it takes you 13 days to do it right, it takes you 13 days, not 10. The restaurant also doesn't tell you that the menu would only costed 5$ if the cook didn't have too clean up the kitchen and sharpen the knives. Seriously.

Ever heard the phrase
"the deadline was yestrerday, but the requirement came in today!".


Well, until they succeed hiring that time travelling wizard, they will have to live with mere mortals working on their problems, I guess... :roll:
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379

BTW, I also read a lot of (well, some) books about Software Design.
And having had that knowledge, I go back to my first post and question -
Why the hell, was this code written this way?


If you remove the hype, I think this question is typically what new methodologies like XP and Agile Dev. are trying to address.

It is all well and good to say that one should have a robust design and a code that reflects it. As you mentioned, in many situations, due to several constraints - human or machine - this is impractical.

So people tend to develop "first-off" or "dirty prototype" or "Proof of Concept" solutions to show something to the manager and the manager - to his manager, and so on.

Given this reality, a good way to counteract this would be to first accept that fact that such PoCs are not going to vanish and that it is better to accept them rather than fight them.

Once your perception has changed and the 'scales have fallen off your eyes' (as Wodehouse says), you can concentrate on the problem of how to refine this code and make it into a robust and deliverable code. I think this is where the concepts of refactoring and TDD come in.

In my reply, I had assumed the language to be Java, for the simple reason that it is what I use. But I believe that the concept of refactoring and TDD is more language independent. True that some languages might be more resistent than others due to their lack of expressiveness. But the bottom line is refactoring is just a way of rearranging your code to make more sense. I think that point can be executed in any language. And you have TDD in almost all flavors now.

I have worked in schedule-driven projects and can relate to your frustration. But of late, I am also trying to see if I can try to change my process to accept the facts than to blame the process itself.

Like Sherlock Holmes said,

It is a capital mistake to theorize before one has facts. One tends to twist facts to suit theory instead of theories to suit facts.
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040
Maulin,

Why we should let that happen?
You see I need a paycheck, so I go with the flow and bottle-up
all that I read/know about software. Afterall, remember its just
a prototype. At the time, the design is being discussed, its for
a prototype remember.

Well Sathya,

Version Control, yeah that already exists.

Now for that "three-box principle"...ummmmm... :roll:
You see, each refactoring takes time. That time needs to be added
to the project plan. That's where things go bad. When you mention
a new feature takes 10 days + I need 3 additional days to refactor,
then you never get those 3 additional days. Ever heard the phrase
"the deadline was yestrerday, but the requirement came in today!".



and finally,

Ilja,

No I don't want my emotions [ ]to be involved in the software.


So looks like there is agreement on the design pattern I discovered, right?
Thanks.
Mani Ram
Ranch Hand

Joined: Mar 11, 2002
Posts: 1140
Originally posted by Ilja Preuss:
BTW, if you need to do a Swing prototype, you might want to use the Napkin Look'n'Feel for it


It's damn cool
I'm going to update all my little utilities with this Look & Feel


Mani
Quaerendo Invenietis
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sathya Srinivasan:
If you remove the hype, I think this question is typically what new methodologies like XP and Agile Dev. are trying to address.

It is all well and good to say that one should have a robust design and a code that reflects it. As you mentioned, in many situations, due to several constraints - human or machine - this is impractical.

So people tend to develop "first-off" or "dirty prototype" or "Proof of Concept" solutions to show something to the manager and the manager - to his manager, and so on.


Well, actually XP would teach to develop a "clean prototype" - one that has the ideal design for what it's currently doing.

I believe that the concept of refactoring and TDD is more language independent.


Agreed. I once applied several refactorings - such as what I would call Extract Clause - to a Prolog program. I think today I would also develop it test-driven.
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040

Given this reality, a good way to counteract this would be to first accept that fact that such PoCs are not going to vanish and that it is better to accept them rather than fight them.

Once your perception has changed and the 'scales have fallen off your eyes' (as Wodehouse says), you can concentrate on the problem of how to refine this code and make it into a robust and deliverable code.


To clarify my stand on the issue,

I am not trying to fight this concept. Instead, as you mentioned, I
accepted it once. Then I observed that it is happening again. Hence, I am merely saying that such architecture suits the design pattern that I posted.

I am not taking sides - good or bad - practical verses bookish!!!
I am just identifying a pattern.

I have no intention of counteracting. Being a developer, I perform
the duties of writing/testing software according to a laid out architecture, which BTW is beyond my control. Hence, I choose not to take
sides. You see my point ?

Thanks.

- m
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040
And BTW, since I don't (and no one else) question(s) the architecture,
its no surprise that its repeated and repeated and hence a pattern...

- m
[ September 30, 2004: Message edited by: Madhav Lakkapragada ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Duct Tape design pattern - just boasting my newest discovery.....
 
Similar Threads
Philosophers stone
List Best Inventions
Geek gang paraphernalia
sevlet
java is broken