Udi Dahan   Udi Dahan – The Software Simplist
Enterprise Development Expert & SOA Specialist
 
   
    Blog Consulting Training Articles Speaking About
  

The Fallacy Of ReUse

Sunday, June 7th, 2009.

This industry is pre-occupied with reuse.

There’s this belief that if we just reused more code, everything would be better.

Some even go so far as saying that the whole point of object-orientation was reuse – it wasn’t, encapsulation was the big thing. After that component-orientation was the thing that was supposed to make reuse happen. Apparently that didn’t pan out so well either because here we are now pinning our reuseful hopes on service-orientation.

Entire books of patterns have been written on how to achieve reuse with the orientation of the day.
Services have been classified every which way in trying to achieve this, from entity services and activity services, through process services and orchestration services. Composing services has been touted as the key to reusing, and creating reusable services.

I might as well let you in on the dirty-little secret:

Reuse is a fallacy

Before running too far ahead, let’s go back to what the actual goal of reuse was: getting done faster.

That’s it.

It’s a fine goal to have.

And here’s how reuse fits in to the picture:

If we were to write all the code of a system, we’d write a certain amount of code.
If we could reuse some code from somewhere else that was written before, we could write less code.
The more code we can reuse, the less code we write.
The less code we write, the sooner we’ll be done!

However, the above logical progression is based on another couple of fallacies:

Fallacy: All code takes the same amount of time to write

Fallacy: Writing code is the primary activity in getting a system done

Anyone who’s actually written some code that’s gone into production knows this.

There’s the time it takes us to understand what the system should do.
Multiply that by the time it takes the users to understand what the system should do :-)
Then there’s the integrating that code with all the other code, databases, configuration, web services, etc.
Debugging. Deploying. Debugging. Rebugging. Meetings. Etc.

Writing code is actually the least of our worries.
We actually spend less time writing code than…

Rebugging code

Also known as bug regressions.

This is where we fix one piece of code, and in the process break another piece of code.
It’s not like we do it on purpose. It’s all those dependencies between the various bits of code.
The more dependencies there are, the more likely something’s gonna break.
Especially when we have all sorts of hidden dependencies,
like when other code uses stuff we put in the database without asking us what it means,
or, heaven forbid, changing it without telling us.

These debugging/rebugging cycles can make stabilizing a system take a long time.

So, how does reuse help/hinder with that?

Here’s how:

Dependencies multiply by reuse

It’s to be expected. If you wrote the code all in one place, there are no dependencies. By reusing code, you’ve created a dependency. The more you reuse, the more dependencies you have. The more dependencies, the more rebugging.

Of course, we need to keep in mind the difference between…

Reuse & Use

Your code uses the runtime API (JDK, .NET BCL, etc).
Likewise other frameworks like (N)Hibernate, Spring, WCF, etc.

Reuse happens when you extend and override existing behaviors within other code.
This is most often done by inheritance in OO languages.

Interestingly enough, by the above generally accepted definition, most web services “reuse” is actually really use.

Let’s take a look at the characteristics of the code we’re using and reusing to see where we get the greatest value:

The value of (re)use

If we were to (re)use a piece of code in only one part of our system, it would be safe to say that we would get less value than if we could (re)use it in more places. For example, we could say that for many web applications, the web framework we use provides more value than a given encryption algorithm that we may use in only a few places.

So, what characterizes the code we use in many places?

Well, it’s very generic.

Actually, the more generic a piece of code, the less likely it is that we’ll be changing something in it when fixing a bug in the system.

That’s important.

However, when looking at the kind of code we reuse, and the reasons around it, we tend to see very non-generic code – something that deals with the domain-specific behaviors of the system. Thus, the likelihood of a bug fix needing to touch that code is higher than in the generic/use-not-reuse case, often much higher.

How it all fits together

Goal: Getting done faster
Via: Spending less time debugging/rebugging/stabilizing
Via: Having less dependencies reasonably requiring a bug fix to touch the dependent side
Via: Not reusing non-generic code

This doesn’t mean you shouldn’t use generic code / frameworks where applicable – absolutely, you should.
Just watch the number of kind of dependencies you introduce.

Back to services

So, if we follow the above advice with services, we wouldn’t want domain specific services reusing each other.
If we could get away with it, we probably wouldn’t even want them using each other either.

As use and reuse go down, we can see that service autonomy goes up. And vice-versa.
Luckily, we have service interaction mechanisms from Event-Driven Architecture that enable use without breaking autonomy.
Autonomy is actually very similar to the principle of encapsulation that drove object-orientation in the first place.
Interesting, isn’t it?

In summary

We all want to get done faster.

Way back when, someone told us reuse was the way to do that.

They were wrong.

Reuse may make sense in the most tightly coupled pieces of code you have, but not very much anywhere else.

When designing services in your SOA, stay away from reuse, and minimize use (with EDA patterns).

The next time someone pulls the “reuse excuse”, you’ll be ready.


Further Reading

  
If you liked this article, you might also like articles in these categories:


Check out my Best Content If you've got a minute, you might enjoy taking a look at some of my best articles.
I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers.
You won't be disappointed.

Subscribe to my feedIf you'd like to get new articles sent to you when they're published, it's easy and free.
Subscribe right here.

Follow me on Twitter Follow me on Twitter @UdiDahan.



Something on your mind? Got a question? I'd be thrilled to hear it.
Leave a comment below or email me, whatever works for you.

53 Comments

  1. Jesper Kamstrup Linnet Says:

    Great post! This is what I have been trying to say every time someone has been beating the “reuse drums”.


  2. Jeppe Cramon Says:

    Awesome post :-)
    Glad to see a well written and explanatory post about my main grudge with traditional SOA use. What most seem to fail is that when they create their big soup of Services with the focus of reuse, they are in fact going against the principle of loosely coupled services. Instead they get high coupling (like when reuse using inheritance in OO). Agree on Event driven Services is one of the better ways of doing SOA without high coupling :-)

    /Jeppe


  3. Chris Bird Says:

    Nice piece, Udi, thanks. 100% agree that SOA isn’t about reuse, but I think it is about refactoring.

    When constructing business processes (externalizing process flow from the service code), I do want to have some components (aka services) that are well enough formed so that they can be invoked at different points in the process.

    Take for example something well formed like a credit check. There are some things I have to know (whose credit I am checking, etc.), the amount of risk I am prepared to take (if the deal is only $5, I may choose to be less careful, but if it is $5,000,000 I may take a great deal more care), and the authority I plan to invoke (internal credit history, external authorities like D&B). So as long as I can establish those things, I can make some choices about when I do the check. At the time the order is placed (in which case I have incurred little or no cost)? Just before I deliver the goods/service (in which case I have incurred some cost)? As I deliver the service (e.g. COD – no pay, no delivery (in which case I have incurred significant transport costs, and have to handle the return too…)

    The point is that when designing the process flow(s), I can choose at which point to make the credit check, whether to do it at all, etc. It could depend on some kind of externalization of policy/process. Policy might be stated as “I will incur minimal cost in the event that credit can not be extended.” So that translates into early credit checking. I might have a policy that says, “Don’t annoy our best customers by denying credit for trivial amounts…” It doesn’t matter for these simplistic examples what policy we have and what the process implications are. What is important is that the component that “checks credit” behaves the same way wherever it is in the process flow. That also means that the component that checks credit delivers an answer, but doesn’t take the action. The process step takes the action.

    So is this reuse? Yes it is – but not in the traditional thinking of reuse. As Udi states normal reuse thinking is indeed a myth. But in the kind of case I am describing here, we have reuse in proper context. I apply the same service invocation at many (possible and unpredictable) points.

    That’s agility, that’s not traditional reuse.


  4. Arjan`s World » LINKBLOG for June 7, 2009 Says:

    [...] The Fallacy Of ReUse – Udi Dahan ‘ This industry is pre-occupied with reuse. There’s this belief that if we just reused more code, everything would be better ‘ [...]


  5. josh Says:

    It’s also a fallacy to think that each time you write particular code takes as long as the first time, and that it comes out the same.

    Personally, I aim to improve with each passing line which tends to improve quality and sometimes increases brevity.


  6. James Leigh Says:

    I agree that reusing code that was not written with the indent of reuse, leads to maintainability problems. However, sometimes the desire for reuse is justified. In these situations the rebugging problems you stated, can be avoid by spending more time and effort on a good API.

    A poorly documented or poorly constructed API (perhaps low cohesion) will lead to more conflicting bugs. A well documented and well constructed API (with high cohesion) makes the desired behaviour obvious by both the code consumer and the code producer.

    When there is a desire for reuse, it has to be balanced with the time/effort to build and maintain an API. There is a trade off with reuse and like everything else, it needs to be managed.


  7. udidahan Says:

    Jesper, Jeppe,

    Glad you liked it.


  8. udidahan Says:

    Chris,

    What you’re describing sounds like a case of *specific use* rather than reuse, which is probably why you haven’t had very many problems with it.

    That being said, I consider the above a credit-check *component*, not a service, as it lacks autonomy – its context is provided to it from outside.

    Thanks for sharing your thoughts.


  9. udidahan Says:

    Josh,

    Good points.


  10. udidahan Says:

    James,

    I tend to agree with you, though I would call out some differences:

    Most APIs you use, not reuse.
    Code that is reused (inherited and overridden), often makes that API less explicit.


  11. Iyigun Cevik Says:

    Udi, Although I generally agree to the idea I have a different view on the topic. Yes, (re)use is sometimes ‘bad’, sometimes ‘good’. You chose to define ‘bad’ as reuse, and good as ‘use’. I see two problems with that:

    1. I believe if we implement parts of ‘code’ which are not coupled to each other there is no problem with reusing them. You’re right, overriding and extending behavior in the code increases the coupling, but therefore we have configuration. All ‘generic’ components you mentioned above allows us to change their behavior by configuring them.
    When we look at the component/library level reuse, most probably your argument about being generic (not domain specific) holds. How about service level? When it comes to service reuse, we are talking about business processes. Completely different topic. Statements about code reuse will not hold there any more. Reuse in library level and service level have very different characteristics. How about event reuse, resource reuse, process reuse? There are many different ways of reuse, I just cannot see how to make a general statement about ‘reuse’.

    2. There are many ways to reuse software or information. Some of them can be harmful but some others are very necessary. If one needs to define some best practices that’s great. But why to change the language we are using by adding/changing definitions? Why to declare things as dead (such as SOA, reuse, etc.) by changing the definitions? Reuse is not always bad. There are bad ways of reuse. SOA is not dead, there are bad ways to do SOA. Tomorrow someone will declare cloud is dead, agile is bad… What’s the point?


  12. udidahan Says:

    Iyigun,

    It’s not that I define ‘bad’ as reuse, but that reuse often (not always) leads to less than stellar results. I’d say that use is preferrable to reuse, but that no dependency would be even better.

    To your question about the service level, my statement is that that is by definition use, and not reuse.

    I wouldn’t say that I’m changing definitions, but rather that I’m trying to give explicit meaning to the difference so that we can make more intelligent choices about what to do when.

    I feel that maybe you read more into my post than I intended – I did not say that SOA was dead, nor do I believe that. Look at the title of my blog :-)

    Hope that clears things up a bit.


  13. Iyigun Cevik Says:

    Udi, this is exactly my point. I think we have very similar opinions about reuse. But when you are redefining concepts on your own, we loose the discussion platform. If a service is used by more than one client, that’s reuse. Very simple, it’s English. You cannot just tell me it’s not reuse by definition.

    I would prefer to have a ubiquitous language first, and then we can go ahead and discuss details of when a reuse is valuable. We can make intelligent choices with the existing definitions as well. We need to explain the differences, we don’t need to change definition of reuse for that.

    “SOA is dead, long live services” was not by you, I wanted to point out to similarities. If you call this entry “Reuse is dead, long live use”, you can see the what i mean.


  14. udidahan Says:

    Iyigun,

    “If a service is used by more than one client, that’s reuse”

    If you say so.

    I guess we’ll have to agree to disagree on this one :-)


  15. Daily Links for Monday, June 8th, 2009 | LaptopHeaven's Blog Says:

    [...] The Fallacy Of ReUse [...]


  16. Chris Bird Says:

    Interesting distinction (back up in the earlier comments). Your statement, “That being said, I consider the above a credit-check *component*, not a service, as it lacks autonomy – its context is provided to it from outside.” has me wondering.

    Is it the case that a service always has complete autonomy? I can see that some services do, but we almost always have to provide data for the service to work on. Yes, that credit check is a (nice?) stateless encapsulation. You tell it who you are asking about, how much is involved and it delivers pass/fail. The tricky part is how much of the who you tell it. If it is a customer id, then we have a real problem, because the component lacks autonomy. If we assemble a bunch of data prior to invocation then that is better. All necessary state is passed in. It is however borderline because you can’t just pass the “amount outstanding, the payment history, the amount requested” into the service and get the answer you want. The answer we want rather depends on things that the credit service/component will need to get from outside. So what to pass? If it is just the id of the customer, the component has to look up the external id (say DUNS) from the database. Makes it more component like than service like. If it is the UNS number, that’s just horrid because I have massively increased coupling – why should the requestor know which agencies are checked? So…

    I ansolutely agree that I am talking specific use – just observing that moving the invocation around in the process is a valuable exercise. My advice, make sure that we externalize the PROCESS from the components.


  17. Alan Huffman Says:

    Udi,

    We are trying to understand what the difference is between USE / REUSE and an autonomous service versus not.

    Could you give some specific examples of… this is USE — this is Reuse. This is autonomous, this is not, this is not even a service though you may think it is?

    Thx for the post — raises some interesting questions/concerns… But we don’t fully grok it.

    -Alan Huffman & Team


  18. udidahan Says:

    Chris,

    “moving the invocation around in the process is a valuable exercise”

    For certain contexts – absolutely. The service is what provides that context :-)


  19. udidahan Says:

    Alan,

    Reuse can be thought of re-purposing a piece of code in a context different than what it was originally in.

    Reuse doesn’t actually happen very much.
    That’s the pernicious thing – there’s this impression that we’re getting value out of something, which is false, and is used to justify adding a dependency without thought of cost.

    When it comes to *using* a “service”, most of the times that’s just glorified procedural programming – with all the problems it brings. Autonomous services rarely, if ever *use* each other – although they do collaborate.

    In short, an autonomous service is one that doesn’t have clients.


  20. Daniel Earwicker Says:

    “In short, an autonomous service is one that doesn’t have clients.”

    Okay, now, you’ve totally lost me. If a tree falls in the forest and there’s no one there to hear it, does it make a sound?

    Generally, this article is pretty baffling. I’ll give my reaction but basically I think I must have missed the point you’re making, so please let me know what I missed.

    The way I write code, the only “context” a piece of code has is the information flowing into it. That code doesn’t care where that information comes from, it only cares what shape it is. It is impossible to distinguish between the users of that code, and that can be proven by unit tests, static typing, or a combination of both. And if it’s impossible to distinguish between the users of the code, then there is no meaningful difference between “use” and “reuse”.

    If two places in my program need to do the same thing, they can either jump to the same shared chunk of code, or they can each contain an embedded duplicate chunk of code. If they choose the latter, then the degrees of freedom are higher, the number of bugs will be statistically larger, the work required to remove them will be greater, the cost will be higher.

    This is why reuse happens all the time, why almost all features of all programming languages invented since 1960 are there to enable reuse, and why it’s the single most important idea in computing.

    You can’t describe building on a framework like .NET as “use” rather than “reuse”, because there are a million other people “using” the same framework, so in fact it’s a massive degree of RE-use.

    Yes, reuse means that you need to understand what a piece of code actually does before you make changes to it, to avoid breaking all the things that depend on it. But is that really news?! That’s always true.

    Every time a function is called, by the same caller, the situation is slightly different (the clock has a different time, for example) and so every time you call a function, even from the same caller, it’s a distinct reuse in which an assumption may be broken. This is why programs sometimes work in the development lab and fail at the customer site. The only way around this is to fully understand what that piece of code is supposed to do, and make sure it does it.

    The only way to reduce the cost of that is to reduce the number of extant duplicates of the same algorithm, by “manual compression” of the source, strenuously identifying duplication and eliminating it.

    The more uses a piece of code has, the more stresses it is placed under, the more feedback you receive about it, the more you find out about it, the stronger it gets.

    And in any case, every line of code should be reused, because it should have multiple tests that call into it and thus depend on it.


  21. udidahan Says:

    Daniel,

    Thank you for your comments – I’ll do my best to address them.

    First, the autonomous service thing. An autonomous service will often contain both client and server components. As such, multiple autonomous services can reside and collaborate together over the same client-server deployment. It’s a different logical division that doesn’t follow tier boundaries. Hope that makes sense. For more info, see this webcast:

    http://www.vimeo.com/5022174

    It sounds like this sentence kind of sums up the value you find reuse brings:

    “The more uses a piece of code has, the more stresses it is placed under, the more feedback you receive about it, the more you find out about it, the stronger it gets.”

    If we take that a step further, that means that that code needs to be taken care of (versioned, bug fixed, features added, backwards compatibility maintained, etc) by the organization forever. If that is a conscious decision, that may be alright. Is all use/reuse subject to that criteria? Not in my experience.

    Here’s a write-up I did for an upcoming O’Reilly book:

    http://commons.oreilly.com/wiki/index.php/Beware_the_Share

    Hope that takes away some of the mysterious zen-ness of it all :-)


  22. Skillful Software » Blog Archive » Clear thinking about code reuse Says:

    [...] Dahan has just fired off a great post about the pitfals of trying to reuse code – that we make big problems for ourselves by trying to re-use domain-specific code into ways it [...]


  23. Daniel Earwicker Says:

    Now I’m even more confused.

    If I have two programs A and B, and I find that they both need to do extract a certain kind of information from (say) an XML file, I write a function to do that, once, and make them both call it. I’d be crazy to (a) write it twice from scratch or (b) write it once but then make unnecessarily divergent copies of the code.

    You seem to be saying that now I’m faced with the “problem” that B might in the future require a different kind of information from its XML file, and so what do I do now? I would – only at this point – diverge the two; if you were close to a release and being very careful, you would literally clone the original code so now you have two very similar functions. But if you have the luxury of time to do the job properly, you would refactor the original function so it is parameterised, allowing it to take care of the common part of both variants – your unit tests prove that you haven’t broken it.

    But, key point, this question doesn’t even arise until I discover that B is calling the wrong method. And when I discover that, I simply change the method that B calls.

    To suggest that (just in case one call site’s requirements change in the future) I should perform a copy-and-paste of every method body before I add a new call to it… no, this is insane! I must just be misreading what you’re saying or missing some huge part of the picture, because what you *seem* to be saying just doesn’t make any sense.


  24. udidahan Says:

    Daniel,

    You seem to be looking at reuse in the context of your own universe. Code that you write, code that you use/reuse elsewhere, code you test, fix, and own.

    What about other peoples code? What about when they use your code without telling you? What about after you leave the organization? What about integrating 2 code bases that reused different versions of the same code?

    “But if you have the luxury of time to do the job properly, you would refactor the original function so it is parameterised”

    Again, what if its not always you?

    The example you gave about reading an XML file can be taken to the generic side – XmlReader, in which case using it in multiple places provides relatively high value, to the specific – assuming that it’s the result of serializing a dataset with a given set of tables, columns, and even rows (for lookup tables).

    Finding the right balance is critical.

    Is that any less confusing?


  25. Richard Says:

    Most of what I call “Reuse” you are calling “Use”. Still, an idea I was taught back in the object oriented days was that a reusable (call it “usable elsewhere” perhaps) piece of code takes about 2.5 times as much time to develop as single purpose code. If you’re going to use it in 3 places then it’s worth it. For some code, using it in 2 places makes it worth it. For some code because of the way the system is subject to change (especially given Agile nowadays) just getting that encapsulation right first time is worth it.

    I’ve seen good results with code reuse, even of the type described as a fallacy here. There are some risks. More generic code can be harder to comprehend because it has to be more abstract conceptually. You have to be sure about that encapsulation and understanding the contract.

    Still, both Use and Reuse can save a lot of time when done well. Imagine the other extreme, having to write boring things like string handling or XML parsing again and again and again.


  26. Daily Links for Monday, June 8th, 2009 Says:

    [...] The Fallacy Of ReUse [...]


  27. udidahan Says:

    Richard,

    I remember that ratio being bandied around too. The thing is, that that’s not what’s important.

    The question is the organization’s commitment to support this code, version it, test it, etc over the lifetime of any and all systems that use it. What happens when a bug is discovered in that code? Are all systems that use it patched? Do we have management in place to know where the code is being used? What if the patch breaks backwards-compatibility? Are we going to support multiple streams in production at the same time?

    There’s more going on than just not writing code.


  28. Mihai Danila Says:

    A play on words that aims to downplay the importance of reuse.

    When you write your second project on the .NET framework, you reuse the framework. Don’t believe you’re doing anything else. Your whole argument should be more careful about the facets of reuse that you find problematic.

    True, there is also the not-so-smart reuse, but that’s not enough to cross the word from our vocabulary when talking about software success stories. I have no doubt that the most successful software reuses a lot. And here I’m referring of course to the frameworks that emerge. Photoshop contains code that applies filters and performs other operations to images — that is code reuse. Polymorphism, Strategy, Adapter are all tools to enable code reuse. The generic sorting method I would have written if someone hadn’t already written for me represents code reuse.

    Cohesive components with a clear statement = reusable code. Componetization goes hand in hand with good reuse. I’d rather reuse the already written inference engines out there than write one from scratch in the name of minimizing, what did you call it, “rebugging”?

    I urge care in the interpretation of words.


  29. Mihai Danila Says:

    I wrote the original coment prior to reading the other comments. I happen to agree with David with regard to many of the points he’s making.

    We live in an imperfect world, and with a lot of complexity, more so on computing than in other aspects of our life. The best method we have to deal with this complexity is reuse. It brings about its own problems, and is often misused, but it’s the best we have.

    I can see how bad reuse in SOA might be more prominent than in software development in general. After all, reuse in coarser grained APIs (I took the liberty of seeing services as APIs) is harder to achieve and the error of trying it erroneously is clearer. But the title of your article makes a much stronger claim, one with which I can’t agree. I would consider toning down the claim laid out in the title — I might see the value of the argument with a punchline like “Reuse in SOA is overrated”.


  30. Kyle Szklenski Says:

    “Actually, the more generic a piece of code, the less likely it is that we’ll be changing something in it when fixing a bug in the system…the likelihood of a bug fix needing to touch that [domain-specific] code is higher than in the generic/use-not-reuse case, often much higher.”

    These statements are fallacious as well. There’s good reason to believe your conclusion is true, but you have not proven it. My reasoning would go more along these lines: You, as a developer, are less likely to know the specific business process so well that you never code any bugs into it with respect to the business needs. Combine that with the fact that you write generic kinds of code all the time for your different applications, and it becomes more likely to make the generic code more robust, and the domain-specific code buggy. You may also need to make a distinction between business-process-buggy and language-syntax-buggy. I would hope that most professional programmers don’t make syntax mistakes (or use a component incorrectly, for example), but we all know that’s going to happen…even quite frequently.

    Having said that, I pretty much fully agree with your post. I realized something similar the other day. In the system I’m working on right now, there’s a lot of gateway/repository use. There is no gateway/repository REuse, though, and that makes me question usefulness of those patterns altogether, at least within the specific context that we’re using them. After all, if one of the interfaces changes, we have to fix all of the various implementations of said interface, which is breaking the whole concept of a closed interface.

    Perhaps that’s a non-terrible way of putting it:
    Reuse of code can only be attained when interfaces are closed.

    Might also need to add the line: … are closed, and that interface’s objects are used throughout the system.

    Not sure if I like that last part. What do you think?

    Mihai, I think you missed a few of the subtleties of his argument, and I don’t think the title of the argument (unless it’s changed since you wrote your last comment) is as powerful a statement as you seem to think.


  31. Aaron Lewis Says:

    Actually, /reuse/ is the process of /reusing/ existing code.

    http://en.wikipedia.org/wiki/Code_reuse

    Of course, reusing code is still using code (using it /again/).

    If you have code that hashes a string and you happen to need to use that same hashing algorithm in another application, you can hopefully reuse it. There may well be no need to extend it, especially if you had written it from the start to be reusable.

    That’s what libraries and frameworks are for! Reuse! Write some code that solves a problem in a reusable way to save time in the many applications that need to solve that same problem.

    Extending and overriding behavior is not reuse. It’s actually somewhat the opposite. Rather than reusing existing code you’re writing new code. You may be reusing design patterns or interfaces, but you’re still writing new code. It’s polymorphism, which is difficult for most people to get right, which explains why it so often leads to poor design and buggy code. If those design patterns or interfaces aren’t applicable to your current application then you probably will spend more time patching, hacking, and debugging then you would have writing from scratch. I call that /abuse/ and /misuse/.


  32. Kyle Szklenski Says:

    Aaron, by that definition, EVERY single piece of code you write is reuse, because after all, you’re using all of the keywords that come with the language, right?

    Since we’re talking about fallacies, I suppose we should bring up the fallacy of equivocation.


  33. ulu Says:

    Udi,

    As I understood, by “use” you mean using your service in several places, and by “reuse” — subclassing a base service class (reusing it) and overriding some members. Am I right?

    How does it correlate with the DRY principle?

    Thanks
    ulu


  34. udidahan Says:

    Mihai,

    Like you said, there’s good (re)use, and there’s bad, which can easily devolve into procedural programming.


  35. udidahan Says:

    Kyle,

    Re, “There’s good reason to believe your conclusion is true, but you have not proven it” – my most expounded apologies :-)

    On “Reuse of code can only be attained when interfaces are closed”, I think we need to add some phrase to the tune of “the purported benefits of code reuse can only be attained…”

    Will probably do a follow-up post.

    Thanks for your comments.


  36. udidahan Says:

    Aaron,

    So it seems that we’re in agreement – there is more difficult (and therefore less common) good kind of use/reuse, and the easier/more common bad kind (abuse).

    This post is in hopes of getting more people to stop and think which one they’re doing before justifying anything and everything with “reuse”.


  37. udidahan Says:

    Ulu,

    The DRY principle – don’t repeat yourself, is not just about specific lines of code, more important is to not duplicate semantics.

    There are other ways of getting the necessary code to run without calling it directly (or via some interface) thus avoiding setting up an additional dependency. Moving the code to an extension point of some framework is one very effective way.

    Does that make sense?


  38. Jonathan Parker Says:

    This is a great post though it doesn’t mention the granularity integration complexity trade-off.

    1. Your whole app is one method:

    0 integration, Infinite complexity in the one method.

    2. Your app is broken into minute components:

    Near-zero complexity in each component, Near-infinite complexity in integration.


  39. udidahan Says:

    Jonathan,

    Good point.


  40. Alberto Brandolini Says:

    Hi Udi,

    I really liked this post.
    I tend also to think about the myth of the reuse in terms of communication costs involved: sometimes just being able to know a that a piece of software does (something similar to) what we need is a cost. And this cost increases with team and project size. So, if the DRY principle makes perfectly sense within a well defined and manageable context, the cost of finding similarities in a large code base is probably higher than the benefits of reuse.

    One thing I really liked is the fact that reuse increases coupling. There is an implicit cost in reusing components, and also in designing for reuse. Too often we tend to forget that.

    Cheers

    Alberto


  41. udidahan Says:

    Alberto,

    Glad you liked it.

    Fully agree with additional communication costs you mention.


  42. Cristian Says:

    It’s interesting to see that most (all) of the examples of reuse when this is discussed are actually reuse of technical infrastructure components, e.g. an XML Parser.

    Reuse is very simple in the technical domain because components are not dependendent on the client’s requirements and therefore not subject to changes in those clients (an XML Parser implements an agreed upon standard that will only change in a very controlled way, and not very often).

    A technical component can be autonomous in that it doesn’t depend on its clients.

    A component implementing logic in a business (functional) domain will be dependent on its specific use by each of its specific clients.
    A service providing customer information may have to accomodate clients from the marketing domain and from the accounting domain.
    New clients and changing requirements in existing clients leads to the rebugging problem that Udi mentions.

    The fallacy is the belief that this functional reuse problem can be solved by technical means (RPC/CORBA/WebServices/etc.), when it’s simply a problem of conceptual dependency between components of a system, regardless of their implementation.


  43. udidahan Says:

    Christian,

    You hit the nail right on the head.


  44. Simon says... : [PL] Having The Infrastructure vs having a infrastructure Says:

    [...] problemu w inny sposób, który w tamtym projekcie może być dużo lepszy. Nawiązując do świetnego posta Udiego, nie widzę już zysku w reużywaniu kodu. Widzę natomiast zysk, i to ogromny, w reużywaniu [...]


  45. Robert Eriksson Says:

    The article generated some good discussions, but considering the amount of confusion it also generated I must ask myself if this is a good article?

    The majority of the posts are about how to use “reuse” and “use” where most people seem to use “reuse” where the author prefers “use”. That most posts discuss “use” vs. “reuse” appears to me as an indication that the article isn’t particularly good.

    In my opinion way to “theoretical” with no real substance and doesn’t touch or addresses the problem around proper reuse (or should I say use so the author gets it?).


  46. udidahan Says:

    Robert,

    You’re certainly entitled to your opinion, both on the topic at hand and my blog in general. In terms of confusion, well, to make an omelet, you’ve got to break some eggs – especially those that people have been using as a crutch. Sometimes, the questions are more important than the answers.

    Thanks again for voicing your thoughts.


  47. Coding: The primitive obsession at Mark Needham Says:

    [...] Udi Dahan explains why this often doesn't work but the problem that I see from this attempt at writing reusable code is that it will get reused in places where the concept doesn't quite make sense. [...]


  48. SOA Manifesto - Colin Jack's Blog - Los Techies : Blogs about software and anything tech! Says:

    [...] in different contexts, such as when you go for an entity service based approach. However there are arguments against too much premature focus on reuse and use is far more important than reuse. I also think that reuse [...]


  49. Clarified CQRS Says:

    [...] thus guiding developers away from introducing dependencies in the name of reuse (it’s a fallacy). If you do decide as a deployment concern, that you want to put them all in the same process [...]


  50. Evert Says:

    Maybe this an old topic, but it is a shame this discussion has never reached mainstream. I am an old programmer, I have seen many APIs, frameworks and systems come and go. And in the end I have always felt that re-usability was a farce.
    No program or system is the same. So code needs to be adapted toe ach specific situation. not only that but the amount of time one may save by not rewriting something is actually wasted in reading the specification or documentation. All these documents, classes, frameworks, APIs have added to the knowledge one must have of programming. Just knowing math, physics, the language and the patterns is no longer enough. We must now know everything about specific libraries of re-usable code.
    I really think the concept of “Don’t repeat yourself” has been taken too far.


  51. Mathias Holmgren Says:

    Awesome! Touche…love it


  52. confidential Says:

    Sorry, but BS. The fact that reusable modules can be poorly designed and that there are more bad than good SW architects out there does not prove that re-use can’t be done successfully.

    But please, just continue with your explanations. It’s nice for us to know that we will outperform you in an heartbeat.


  53. Jun-Dai Says:

    I agree that re-use is over-emphasised and that DRY is a philosophy that should be used carefully.

    That said, you’re completely wrong on a basic assumption of your argument, which is that the sole purpose of code reuse is “getting done faster”. I don’t know of anyone that applies principles of DRY for that purpose, and on the contrary avoiding code reuse often takes longer as you have to carefully extract re-usable components into a shared location. I’ve never heard of “getting done faster” as an argument for code reuse, which kind of makes this whole post a straw man.

    The main purposes of code reuse are:
    * reduce bugs by improving encapsulation (an important side effect of making code reusable)
    * improve maintainability by reducing code
    * improve maintainability by reducing the number of locations that have to be touched when fixing a single bug.

    With that in mind, code reuse forces coupling, and that is what has to be weighed when considering the value of DRY. Over-application of DRY results in an extremely complex diagram of dependencies. I think it’s generally best to apply DRY where reusability is clearly apparent, but to avoid torturing your code in the process.


Your comment...



If this is your first time commenting, it may take a while to show up.
I'm working to make that better.

Subscribe here to receive updates on comments.
  
   


Don't miss my best content
 
Locations of visitors to this page

Recommendations

Bryan Wheeler, Director Platform Development at msnbc.com
Udi Dahan is the real deal.

We brought him on site to give our development staff the 5-day “Advanced Distributed System Design” training. The course profoundly changed our understanding and approach to SOA and distributed systems.

Consider some of the evidence: 1. Months later, developers still make allusions to concepts learned in the course nearly every day 2. One of our developers went home and made her husband (a developer at another company) sign up for the course at a subsequent date/venue 3. Based on what we learned, we’ve made constant improvements to our architecture that have helped us to adapt to our ever changing business domain at scale and speed If you have the opportunity to receive the training, you will make a substantial paradigm shift.

If I were to do the whole thing over again, I’d start the week by playing the clip from the Matrix where Morpheus offers Neo the choice between the red and blue pills. Once you make the intellectual leap, you’ll never look at distributed systems the same way.

Beyond the training, we were able to spend some time with Udi discussing issues unique to our business domain. Because Udi is a rare combination of a big picture thinker and a low level doer, he can quickly hone in on various issues and quickly make good (if not startling) recommendations to help solve tough technical issues.” November 11, 2010

Sam Gentile Sam Gentile, Independent WCF & SOA Expert
“Udi, one of the great minds in this area.
A man I respect immensely.”





Ian Robinson Ian Robinson, Principal Consultant at ThoughtWorks
"Your blog and articles have been enormously useful in shaping, testing and refining my own approach to delivering on SOA initiatives over the last few years. Over and against a certain 3-layer-application-architecture-blown-out-to- distributed-proportions school of SOA, your writing, steers a far more valuable course."

Shy Cohen Shy Cohen, Senior Program Manager at Microsoft
“Udi is a world renowned software architect and speaker. I met Udi at a conference that we were both speaking at, and immediately recognized his keen insight and razor-sharp intellect. Our shared passion for SOA and the advancement of its practice launched a discussion that lasted into the small hours of the night.
It was evident through that discussion that Udi is one of the most knowledgeable people in the SOA space. It was also clear why – Udi does not settle for mediocrity, and seeks to fully understand (or define) the logic and principles behind things.
Humble yet uncompromising, Udi is a pleasure to interact with.”

Glenn Block Glenn Block, Senior Program Manager - WCF at Microsoft
“I have known Udi for many years having attended his workshops and having several personal interactions including working with him when we were building our Composite Application Guidance in patterns & practices. What impresses me about Udi is his deep insight into how to address business problems through sound architecture. Backed by many years of building mission critical real world distributed systems it is no wonder that Udi is the best at what he does. When customers have deep issues with their system design, I point them Udi's way.”

Karl Wannenmacher Karl Wannenmacher, Senior Lead Expert at Frequentis AG
“I have been following Udi’s blog and podcasts since 2007. I’m convinced that he is one of the most knowledgeable and experienced people in the field of SOA, EDA and large scale systems.
Udi helped Frequentis to design a major subsystem of a large mission critical system with a nationwide deployment based on NServiceBus. It was impressive to see how he took the initial architecture and turned it upside down leading to a very flexible and scalable yet simple system without knowing the details of the business domain. I highly recommend consulting with Udi when it comes to large scale mission critical systems in any domain.”

Simon Segal Simon Segal, Independent Consultant
“Udi is one of the outstanding software development minds in the world today, his vast insights into Service Oriented Architectures and Smart Clients in particular are indeed a rare commodity. Udi is also an exceptional teacher and can help lead teams to fall into the pit of success. I would recommend Udi to anyone considering some Architecural guidance and support in their next project.”

Ohad Israeli Ohad Israeli, Chief Architect at Hewlett-Packard, Indigo Division
“When you need a man to do the job Udi is your man! No matter if you are facing near deadline deadlock or at the early stages of your development, if you have a problem Udi is the one who will probably be able to solve it, with his large experience at the industry and his widely horizons of thinking , he is always full of just in place great architectural ideas.
I am honored to have Udi as a colleague and a friend (plus having his cell phone on my speed dial).”

Ward Bell Ward Bell, VP Product Development at IdeaBlade
“Everyone will tell you how smart and knowledgable Udi is ... and they are oh-so-right. Let me add that Udi is a smart LISTENER. He's always calibrating what he has to offer with your needs and your experience ... looking for the fit. He has strongly held views ... and the ability to temper them with the nuances of the situation.
I trust Udi to tell me what I need to hear, even if I don't want to hear it, ... in a way that I can hear it. That's a rare skill to go along with his command and intelligence.”

Eli Brin, Program Manager at RISCO Group
“We hired Udi as a SOA specialist for a large scale project. The development is outsourced to India. SOA is a buzzword used almost for anything today. We wanted to understand what SOA really is, and what is the meaning and practice to develop a SOA based system.
We identified Udi as the one that can put some sense and order in our minds. We started with a private customized SOA training for the entire team in Israel. After that I had several focused sessions regarding our architecture and design.
I will summarize it simply (as he is the software simplist): We are very happy to have Udi in our project. It has a great benefit. We feel good and assured with the knowledge and practice he brings. He doesn’t talk over our heads. We assimilated nServicebus as the ESB of the project. I highly recommend you to bring Udi into your project.”

Catherine Hole Catherine Hole, Senior Project Manager at the Norwegian Health Network
“My colleagues and I have spent five interesting days with Udi - diving into the many aspects of SOA. Udi has shown impressive abilities of understanding organizational challenges, and has brought the business perspective into our way of looking at services. He has an excellent understanding of the many layers from business at the top to the technical infrstructure at the bottom. He is a great listener, and manages to simplify challenges in a way that is understandable both for developers and CEOs, and all the specialists in between.”

Yoel Arnon Yoel Arnon, MSMQ Expert
“Udi has a unique, in depth understanding of service oriented architecture and how it should be used in the real world, combined with excellent presentation skills. I think Udi should be a premier choice for a consultant or architect of distributed systems.”

Vadim Mesonzhnik, Development Project Lead at Polycom
“When we were faced with a task of creating a high performance server for a video-tele conferencing domain we decided to opt for a stateless cluster with SQL server approach. In order to confirm our decision we invited Udi.

After carefully listening for 2 hours he said: "With your kind of high availability and performance requirements you don’t want to go with stateless architecture."

One simple sentence saved us from implementing a wrong product and finding that out after years of development. No matter whether our former decisions were confirmed or altered, it gave us great confidence to move forward relying on the experience, industry best-practices and time-proven techniques that Udi shared with us.
It was a distinct pleasure and a unique opportunity to learn from someone who is among the best at what he does.”

Jack Van Hoof Jack Van Hoof, Enterprise Integration Architect at Dutch Railways
“Udi is a respected visionary on SOA and EDA, whose opinion I most of the time (if not always) highly agree with. The nice thing about Udi is that he is able to explain architectural concepts in terms of practical code-level examples.”

Neil Robbins Neil Robbins, Applications Architect at Brit Insurance
“Having followed Udi's blog and other writings for a number of years I attended Udi's two day course on 'Loosely Coupled Messaging with NServiceBus' at SkillsMatter, London.

I would strongly recommend this course to anyone with an interest in how to develop IT systems which provide immediate and future fitness for purpose. An influential and innovative thought leader and practitioner in his field, Udi demonstrates and shares a phenomenally in depth knowledge that proves his position as one of the premier experts in his field globally.

The course has enhanced my knowledge and skills in ways that I am able to immediately apply to provide benefits to my employer. Additionally though I will be able to build upon what I learned in my 2 days with Udi and have no doubt that it will only enhance my future career.

I cannot recommend Udi, and his courses, highly enough.”

Nick Malik Nick Malik, Enterprise Architect at Microsoft Corporation
You are an excellent speaker and trainer, Udi, and I've had the fortunate experience of having attended one of your presentations. I believe that you are a knowledgable and intelligent man.”

Sean Farmar Sean Farmar, Chief Technical Architect at Candidate Manager Ltd
“Udi has provided us with guidance in system architecture and supports our implementation of NServiceBus in our core business application.

He accompanied us in all stages of our development cycle and helped us put vision into real life distributed scalable software. He brought fresh thinking, great in depth of understanding software, and ongoing support that proved as valuable and cost effective.

Udi has the unique ability to analyze the business problem and come up with a simple and elegant solution for the code and the business alike.
With Udi's attention to details, and knowledge we avoided pit falls that would cost us dearly.”

Børge Hansen Børge Hansen, Architect Advisor at Microsoft
“Udi delivered a 5 hour long workshop on SOA for aspiring architects in Norway. While keeping everyone awake and excited Udi gave us some great insights and really delivered on making complex software challenges simple. Truly the software simplist.”

Motty Cohen, SW Manager at KorenTec Technologies
“I know Udi very well from our mutual work at KorenTec. During the analysis and design of a complex, distributed C4I system - where the basic concepts of NServiceBus start to emerge - I gained a lot of "Udi's hours" so I can surely say that he is a professional, skilled architect with fresh ideas and unique perspective for solving complex architecture challenges. His ideas, concepts and parts of the artifacts are the basis of several state-of-the-art C4I systems that I was involved in their architecture design.”

Aaron Jensen Aaron Jensen, VP of Engineering at Eleutian Technology
Awesome. Just awesome.

We’d been meaning to delve into messaging at Eleutian after multiple discussions with and blog posts from Greg Young and Udi Dahan in the past. We weren’t entirely sure where to start, how to start, what tools to use, how to use them, etc. Being able to sit in a room with Udi for an entire week while he described exactly how, why and what he does to tackle a massive enterprise system was invaluable to say the least.

We now have a much better direction and, more importantly, have the confidence we need to start introducing these powerful concepts into production at Eleutian.”

Gad Rosenthal Gad Rosenthal, Department Manager at Retalix
“A thinking person. Brought fresh and valuable ideas that helped us in architecting our product. When recommending a solution he supports it with evidence and detail so you can successfully act based on it. Udi's support "comes on all levels" - As the solution architect through to the detailed class design. Trustworthy!”

Chris Bilson Chris Bilson, Developer at Russell Investment Group
“I had the pleasure of attending a workshop Udi led at the Seattle ALT.NET conference in February 2009. I have been reading Udi's articles and listening to his podcasts for a long time and have always looked to him as a source of advice on software architecture.
When I actually met him and talked to him I was even more impressed. Not only is Udi an extremely likable person, he's got that rare gift of being able to explain complex concepts and ideas in a way that is easy to understand.
All the attendees of the workshop greatly appreciate the time he spent with us and the amazing insights into service oriented architecture he shared with us.”

Alexey Shestialtynov Alexey Shestialtynov, Senior .Net Developer at Candidate Manager
“I met Udi at Candidate Manager where he was brought in part-time as a consultant to help the company make its flagship product more scalable. For me, even after 30 years in software development, working with Udi was a great learning experience. I simply love his fresh ideas and architecture insights.
As we all know it is not enough to be armed with best tools and technologies to be successful in software - there is still human factor involved. When, as it happens, the project got in trouble, management asked Udi to step into a leadership role and bring it back on track. This he did in the span of a month. I can only wish that things had been done this way from the very beginning.
I look forward to working with Udi again in the future.”

Christopher Bennage Christopher Bennage, President at Blue Spire Consulting, Inc.
“My company was hired to be the primary development team for a large scale and highly distributed application. Since these are not necessarily everyday requirements, we wanted to bring in some additional expertise. We chose Udi because of his blogging, podcasting, and speaking. We asked him to to review our architectural strategy as well as the overall viability of project.
I was very impressed, as Udi demonstrated a broad understanding of the sorts of problems we would face. His advice was honest and unbiased and very pragmatic. Whenever I questioned him on particular points, he was able to backup his opinion with real life examples. I was also impressed with his clarity and precision. He was very careful to untangle the meaning of words that might be overloaded or otherwise confusing. While Udi's hourly rate may not be the cheapest, the ROI is undoubtedly a deal. I would highly recommend consulting with Udi.”

Robert Lewkovich, Product / Development Manager at Eggs Overnight
“Udi's advice and consulting were a huge time saver for the project I'm responsible for. The $ spent were well worth it and provided me with a more complete understanding of nServiceBus and most importantly in helping make the correct architectural decisions earlier thereby reducing later, and more expensive, rework.”

Ray Houston Ray Houston, Director of Development at TOPAZ Technologies
“Udi's SOA class made me smart - it was awesome.

The class was very well put together. The materials were clear and concise and Udi did a fantastic job presenting it. It was a good mixture of lecture, coding, and question and answer. I fully expected that I would be taking notes like crazy, but it was so well laid out that the only thing I wrote down the entire course was what I wanted for lunch. Udi provided us with all the lecture materials and everyone has access to all of the samples which are in the nServiceBus trunk.

Now I know why Udi is the "Software Simplist." I was amazed to find that all the code and solutions were indeed very simple. The patterns that Udi presented keep things simple by isolating complexity so that it doesn't creep into your day to day code. The domain code looks the same if it's running in a single process or if it's running in 100 processes.”

Ian Cooper Ian Cooper, Team Lead at Beazley
“Udi is one of the leaders in the .Net development community, one of the truly smart guys who do not just get best architectural practice well enough to educate others but drives innovation. Udi consistently challenges my thinking in ways that make me better at what I do.”

Liron Levy, Team Leader at Rafael
“I've met Udi when I worked as a team leader in Rafael. One of the most senior managers there knew Udi because he was doing superb architecture job in another Rafael project and he recommended bringing him on board to help the project I was leading.
Udi brought with him fresh solutions and invaluable deep architecture insights. He is an authority on SOA (service oriented architecture) and this was a tremendous help in our project.
On the personal level - Udi is a great communicator and can persuade even the most difficult audiences (I was part of such an audience myself..) by bringing sound explanations that draw on his extensive knowledge in the software business. Working with Udi was a great learning experience for me, and I'll be happy to work with him again in the future.”

Adam Dymitruk Adam Dymitruk, Director of IT at Apara Systems
“I met Udi for the first time at DevTeach in Montreal back in early 2007. While Udi is usually involved in SOA subjects, his knowledge spans all of a software development company's concerns. I would not hesitate to recommend Udi for any company that needs excellent leadership, mentoring, problem solving, application of patterns, implementation of methodologies and straight out solution development.
There are very few people in the world that are as dedicated to their craft as Udi is to his. At ALT.NET Seattle, Udi explained many core ideas about SOA. The team that I brought with me found his workshop and other talks the highlight of the event and provided the most value to us and our organization. I am thrilled to have the opportunity to recommend him.”

Eytan Michaeli Eytan Michaeli, CTO Korentec
“Udi was responsible for a major project in the company, and as a chief architect designed a complex multi server C4I system with many innovations and excellent performance.”


Carl Kenne Carl Kenne, .Net Consultant at Dotway AB
“Udi's session "DDD in Enterprise apps" was truly an eye opener. Udi has a great ability to explain complex enterprise designs in a very comprehensive and inspiring way. I've seen several sessions on both DDD and SOA in the past, but Udi puts it in a completly new perspective and makes us understand what it's all really about. If you ever have a chance to see any of Udi's sessions in the future, take it!”

Avi Nehama, R&D Project Manager at Retalix
“Not only that Udi is a briliant software architecture consultant, he also has remarkable abilities to present complex ideas in a simple and concise manner, and...
always with a smile. Udi is indeed a top-league professional!”

Ben Scheirman Ben Scheirman, Lead Developer at CenterPoint Energy
“Udi is one of those rare people who not only deeply understands SOA and domain driven design, but also eloquently conveys that in an easy to grasp way. He is patient, polite, and easy to talk to. I'm extremely glad I came to his workshop on SOA.”

Scott C. Reynolds Scott C. Reynolds, Director of Software Engineering at CBLPath
“Udi is consistently advancing the state of thought in software architecture, service orientation, and domain modeling.
His mastery of the technologies and techniques is second to none, but he pairs that with a singular ability to listen and communicate effectively with all parties, technical and non, to help people arrive at context-appropriate solutions. Every time I have worked with Udi, or attended a talk of his, or just had a conversation with him I have come away from it enriched with new understanding about the ideas discussed.”

Evgeny-Hen Osipow, Head of R&D at PCLine
“Udi has helped PCLine on projects by implementing architectural blueprints demonstrating the value of simple design and code.”

Rhys Campbell Rhys Campbell, Owner at Artemis West
“For many years I have been following the works of Udi. His explanation of often complex design and architectural concepts are so cleanly broken down that even the most junior of architects can begin to understand these concepts. These concepts however tend to typify the "real world" problems we face daily so even the most experienced software expert will find himself in an "Aha!" moment when following Udi teachings.
It was a pleasure to finally meet Udi in Seattle Alt.Net OpenSpaces 2008, where I was pleasantly surprised at how down-to-earth and approachable he was. His depth and breadth of software knowledge also became apparent when discussion with his peers quickly dove deep in to the problems we current face. If given the opportunity to work with or recommend Udi I would quickly take that chance. When I think .Net Architecture, I think Udi.”

Sverre Hundeide Sverre Hundeide, Senior Consultant at Objectware
“Udi had been hired to present the third LEAP master class in Oslo. He is an well known international expert on enterprise software architecture and design, and is the author of the open source messaging framework nServiceBus. The entire class was based on discussion and interaction with the audience, and the only Power Point slide used was the one showing the agenda.
He started out with sketching a naive traditional n-tier application (big ball of mud), and based on suggestions from the audience we explored different solutions which might improve the solution. Whatever suggestions we threw at him, he always had a thoroughly considered answer describing pros and cons with the suggested solution. He obviously has a lot of experience with real world enterprise SOA applications.”

Raphaël Wouters Raphaël Wouters, Owner/Managing Partner at Medinternals
“I attended Udi's excellent course 'Advanced Distributed System Design with SOA and DDD' at Skillsmatter. Few people can truly claim such a high skill and expertise level, present it using a pragmatic, concrete no-nonsense approach and still stay reachable.”

Nimrod Peleg Nimrod Peleg, Lab Engineer at Technion IIT
“One of the best programmers and software engineer I've ever met, creative, knows how to design and implemet, very collaborative and finally - the applications he designed implemeted work for many years without any problems!

Jose Manuel Beas
“When I attended Udi's SOA Workshop, then it suddenly changed my view of what Service Oriented Architectures were all about. Udi explained complex concepts very clearly and created a very productive discussion environment where all the attendees could learn a lot. I strongly recommend hiring Udi.”

Daniel Jin Daniel Jin, Senior Lead Developer at PJM Interconnection
“Udi is one of the top SOA guru in the .NET space. He is always eager to help others by sharing his knowledge and experiences. His blog articles often offer deep insights and is a invaluable resource. I highly recommend him.”

Pasi Taive Pasi Taive, Chief Architect at Tieto
“I attended both of Udi's "UI Composition Key to SOA Success" and "DDD in Enterprise Apps" sessions and they were exceptionally good. I will definitely participate in his sessions again. Udi is a great presenter and has the ability to explain complex issues in a manner that everyone understands.”

Eran Sagi, Software Architect at HP
“So far, I heard about Service Oriented architecture all over. Everyone mentions it – the big buzz word. But, when I actually asked someone for what does it really mean, no one managed to give me a complete satisfied answer. Finally in his excellent course “Advanced Distributed Systems”, I got the answers I was looking for. Udi went over the different motivations (principles) of Services Oriented, explained them well one by one, and showed how each one could be technically addressed using NService bus. In his course, Udi also explain the way of thinking when coming to design a Service Oriented system. What are the questions you need to ask yourself in order to shape your system, place the logic in the right places for best Service Oriented system.

I would recommend this course for any architect or developer who deals with distributed system, but not only. In my work we do not have a real distributed system, but one PC which host both the UI application and the different services inside, all communicating via WCF. I found that many of the architecture principles and motivations of SOA apply for our system as well. Enough that you have SW partitioned into components and most of the principles becomes relevant to you as well. Bottom line – an excellent course recommended to any SW Architect, or any developer dealing with distributed system.”

Consult with Udi

Guest Authored Books
Chapter: Introduction to SOA    Article: The Enterprise Service Bus and Your SOA

97 Things Every Software Architect Should Know



Creative Commons License  © Copyright 2005-2011, Udi Dahan. email@UdiDahan.com    Freely hosted by Weblogs.us