My employer's legacy system started off (in 1997) as very structured procedural code (with a smidgeon of OO), and it was luckily one of the 10% of software projects that was successful. It may look a little antequated today, but at least it is structured and provided a framework to hang extensions upon.

Fast forward to the late 2000's and developers not connected with the original architects have bit by bit extended the system in an ad hoc way with no architecture, just making decisions as they went along, going with what seemed to make sense to them at the time. They also abandoned any naming or coding conventions. To over-simplify, they never make a class, never make anything for re-use, and the only consideration is: "will it break what is already there?" which puts a damper on more innovative approaches. There is still lots of VB6 code.

These developers are still there, and they are entrenched, and can patch the system, or do things allow by the original architects, very fast.

However, since there is zero code reuse, they have no building blocks with which to build an entirely new system, so they can't do anything really special or novel for a prospective client, even a giant one like Sams Club.

I recall there were some really good arguments for improving code quality, for example, by using OO methodology, in money terms that would get an executive's attention, but I can't recall where I saw it. It has been a while. I intuitively sense that gathering all functionality into a class provides the most flexibility and maintainability but I don't have any ammo.

Some of the thoughts I'm up against include: The system seems to be working "just fine". So why should we rock the boat with something like a "quality program"? The current developers love it the way it is, so they don't want to do anything to improve their code or the quality of the architecture. They know every one of the 73 places a certain quantity is referenced. Who needs it? T-Sql doesn't need to be compiled! Copy and pasting the same code localizes bugs to that particular copy.


It was unclear what I was asking, huh? Well, the answer accepted contains a comment that has a link (http://blog.codinghorror.com/the-big-ball-of-mud-and-other-architectural-disasters/) that was exactly what I was looking for, so I marked as answer. So, someone, perhaps several people, inherently knew what I was asking anyway. If you read the article sited, you'll see that actually what I'm going thru here is common. I am very much not alone in this, which makes me feel better. :-)

  • 1
    So what is the actual question? The source of the quote? In that case, the question is off-topic. – Arseni Mourzenko Nov 7 '14 at 23:03
  • sources wouldn't be the full answer, because they don't indicate what's tried an true via actual experience with managers, which is what this site pre-eminently provides. – toddmo Nov 7 '14 at 23:11
  • When talking to managers, forget terms like "OO" and just focus what the actual problems are. (I.e. expand on your fourth paragraph and your "...puts a damper on more innovative approaches" comment.) – Gort the Robot Nov 7 '14 at 23:38
  • 1
    The current non-strucuted, non OO developers love it the way it is, so they don't want anything to do with OO -> to me it seems you are wrong in this company. Go and search for a company that knows the value of your knowledge. You certainly won't be able to change how these people work if they don't want it themselves. Chances that you or management can force them now after all this time are quite low now. Sorry, but this is how I see it... – valenterry Nov 7 '14 at 23:54
  • 1
    I would suggest reading How do I explain ${something} to ${someone}? ad consider how the question could be altered to a problem that you wish to solve with the architecture and design rather than one of how to win an argument. – user40980 Nov 8 '14 at 1:13

You original question seemed to reflect a misconception - one of top 10 false assumptions about OO: the belief that object orientation will imply more code reuse and less duplicated code.

That is a fallacy!

If you have devs who care for DRY code, care for reuse and who have learnt and understood OO principles, they can use the latter to build better, more reusable software. But it never works the other way round - just introducing some object orientation to a team of people who do not care for the things I mentioned before will not change any of their bad habits.

So I guess what you are really after is something like a quality offensive to work actively against the famous big-ball-of-mud architecture. Note that the article behind this link does not contain the word "object orientation". Actually, it also does not contain any arguments in terms of money (but I guess the comparisons and pictures used there are nonetheless understandable for most managers).

|improve this answer|||||
  • I'm only concerned with the manager. Those non-DRY programmers will become that small maintenance crew for the legacy system some day and will be looking for jobs when the last part of that legacy system is replaced with architecture. I assume they will not change. I have to work completely around them. – toddmo Nov 8 '14 at 0:07
  • @toddmo: if you want to ask a question about management or architecture, you should not intermix this with object orientation. I guess this blog post might be of interest for you. blog.codinghorror.com/… – Doc Brown Nov 8 '14 at 7:50
  • That article is exactly what I needed. Thanks Doc. – toddmo Nov 8 '14 at 20:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.