Phillip Trelford's Array

POKE 36879,255


Are you working in the enterprise?

Do you find yourself, day-in-day-out, up to the eyeballs in unmaintainable code?

Does the once beautiful architecture now more closely resemble a big ball of mud, that no amount of tooling will dig you out of?

What can you do?

1) Bury your head in the sand


A very popular option, you just need to keep practising denial.

2) Turn to drink


Another popular option, although unfortunately this strategy is only likely to last as long as your liver.

3) Become a scrum master

scrum master

This is an easy way out, scrum certification is just a 2 day course away, but there’s probably no looking back.

4) Admit there’s a problem


This is one of the hardest and least popular options, but possibly the most rewarding.

Start by saying out loud: “Object Oriented Programming is an expensive disaster which must end” and then take each new day as it comes.

Comments (6) -

  • Pasho

    10/7/2014 4:20:13 PM |

    I think the main killer is the over-engineering in uncertainty. Not knowing the problem or not knowing enough at the start. Business doesn't know the exact problem either. Both of you will figure it out as the delivery goes and the right questions arise. So being prepared for the radical changes is the key (throwing away big chunks and rewriting quickly from scratch). Complex OO designs with lots of conventions and rules picked from some good books don't work like that. Simple solutions do better, even object oriented.

    How to avoid over-engineering? Dunno, time constraints can bring a challenge - without pressure I would finish this in a week, but we need a result tomorrow, is there an easier way?

  • Phil

    10/8/2014 12:09:38 AM |

    Paulo, I wholeheartedly agree with you on heading towards simpler solutions and being prepared for more radical changes.
    I've found focusing more on modular programming through separating concerns and minimizing dependencies makes changing functionality over time a lot easier. However, although this is achievable in mainstream OO P languages, I feel the combination of deadlines in enterprise combined with the ease at which cyclic dependencies can be introduced means that this is more often the exception rather than the rule.

  • Pasho

    10/8/2014 2:36:20 AM |

    Modularity - that's exactly what we do. The best thing - I can start building each new module with new ideas and lessons learned. I'm not too fuss about OOP or any other approach. My C# code consists of lambdas and extensions a little less than completely. I'd probably go F#, but some things I want require the latest versions of everything, which is another massive problem in big companies, partly caused by the legacy zoo of all those marvellous enterprise architecture creatures.

  • Paul Gehrman

    10/9/2014 8:37:11 AM |

    Sadly, OOP is a religion and, like most religions, is hard to get rid of. The good news is that a fairly high percentage of experienced developers realize that OOP has substantial failings and is philosophically flawed. The bigger problem is new developers coming out of school who are still drunk from the OOP Kool-Aid.

  • davet

    10/9/2014 8:14:59 PM |

    As I started reading "Object Oriented Programming is an expensive disaster which must end" I immediately thought that I had clicked on the wrong article and that what I was reading was about the Agile methodology because of the True Scotsman thing.

    Person A: Agile projects can't fail.
    Person B: My Agile project failed.
    Person A: True Agile projects can't fail.

  • Dev

    10/10/2014 2:05:35 AM |

    Oh, so using e.g. F# is not an option? Because it's an OOP language just as much as e.g. C# is a functional language. Does it leave us with Haskell? I'd like to see that - thousands of developers all over the world spending most of their time arguing about merits of some homomorphic applicative endo-functors.

Pingbacks and trackbacks (1)+

Comments are closed