3

I am lead developer and team lead in a small RAD team. Deadlines are tight and we have to release often, which we do, and this is what keep the business happy.

While we (the development team) are trying to maintain the quality of the code (clean and short methods), I can't help but notice that the overall quality of the OO design&architecture is getting worse over the time - the library we are working on is gradually reducing itself to a "bag of functions". Well, we try to use the design patterns, but since we don't really have much time for a design as such we are mostly using the creational ones.

I have read Code Complete / Design Patterns (GOF & enterprise) / Progmatic Programmer / and many books from Effective XXX series. Should I re-read them again as I have read them a long time ago and forgotten quite a lot, or there are other / better OO design / software architeture books been published since then which I should definitely read?

Any ideas, recommendations on how can I get the situation under control and start improving the architecture. The way I see it - I will start improving the architectural / design quality of software components I am working on and then will start helping other team members once I find what is working for me.

Improve this question

5 Answers 5

Reset to default
13

Am I right in my assumption that you don't do any unit testing? Unit testing is a great way to show you where you design/architecture lacks... if you are not able to test classes in isolation, your design may be broken... if it is reeeaaally hard to write tests for your classes, this may also be a sign that the design could be improved. Unit testing taught me more about proper design than any book out there...

Improve this answer
3
  • 2
    I would add more than +1 if it was possible...
    – herby
    Sep 6, 2012 at 13:31
  • +1 with caveat: Integration testing in the guise of unit testing gives an extreme false confidence to people. Integration tests are capable of finding bugs, but unit testing is the only form of testing that actually susses out architectural/design issues.
    – Jimmy Hoffa
    Sep 6, 2012 at 15:40
  • @oliver-weiler. Thanks Oliver. Your assumption is right. Alas, we don't do unit testing here, but I used to be doing quite a bit of TDD development in other companies, but I fail too see how come unit testing can help me to up skill myself in design/architecture. We could certainly benefit from unit testing, but being pressed by the deadlines will likely to resort testing a big chunks of functionality (is it what Jimmy-Hoffa calls by "Integration testing"?) which would not make me to re-think or change the design of the smaller components (what constitutes the big chunk).
    – PeterT
    Sep 7, 2012 at 10:37
2

My two suggestions would be on the one hand, go back to the fundamentals, and on the other hand add to those fundamentals in your tool box:

Back to the fundamentals: Design principles are the fundamental elements that drive design patterns, without principles to strive for all those formal patterns wouldn't exist. Start with SOLID http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) and go into pieces of the code you feel have become bumpy and start assessing which principles are being broken and why. For future code you write, with each class or method or design you begin to implement, ask yourself if it's obeying the principles or breaking any of them.

Adding fundamentals: You mention OO and clearly have a strong drive towards this direction, but OO designs can often be improved through understanding of the functional paradigm and how it achieves compliance with design principles. If you haven't learned any functional languages, go learn Haskell or f# or Clojure or any of them really (Haskell will literally give you a headache, and simultaneously change your mind for you). Just learning and practicing one of these for a month in your spare time will give you new tools which will allow you to more easily and comprehensively obey good design principles in scenarios where maybe the OO approaches just didn't quite meet good design.

Improve this answer
2

Another approach for an refreshment is Clean Coders. It's a collection of videos from Uncle Bob (Robert C. Martin).

Look at the headlines of these videos. You will see that they are mostly about TDD, Clean Code, SOLID and Component Patterns. Our team is watching one video per week (with a discussion afterwards) to have a common understanding what principles we want to follow. Unit testing for example... and the videos explaining very good, how to do it and how to start.

Improve this answer
2
  • I am a bit sceptical about this "video course". I don't mind to pay for a good product, but judging by episode screenshots, as Uncle Bob decided not to make even a shortest preview for free, it looks too "unconventional" to be useful.
    – PeterT
    Sep 7, 2012 at 12:35
  • 1
    Do you know the book "Clean Code" or "The Clean Coder". The videos are about the topics in this books. And yes the videos are unconventional from the pictures and costumes but not from the software development perspective.
    – ollins
    Sep 8, 2012 at 6:33
1

Giving releases often means that the code is changing all the time: small improvements, new features, additional functionality, etc. So the main rule (as my college says) is to keep in mind that whatever you write today will be changed tomorrow. The whole system should be extremely flexible and simple, so that changes will not break it's architecture or cause any other problems.

If you don't have enough time to design everything well, I'm pretty sure it's your management's fault. They keep pushing you, so you have to produce working code all the time. Try to convince them that creating good design from the beginning is essential: it will save time in future. Otherwise you risk to have a pile of working but unmanageable code. Besides, the better the design is, the less time coding requires. When everything is thought out thoroughly, there's very little left to do.

You could also consider code reviewing. Development will take longer, but a lot more time will be saved on fixing bugs.

In the company I work, every piece of somewhat big design is discussed with our team-leader. Nothing is coded without his OK. I assume, you should be the very person in your team who would approve design. If you think you don't have enough skills, you could do this together with other members of your team, who are most skillful. During code reviews you could gather the whole team and tell them about those improvements: how and why they were made. This is important, because (a) everyone will learn and (b) there is a big chance you'll get some good ideas from you less experienced colleges.

Improve this answer
3
  • We already do the code review and this is what keep the code quality (at the method level) high. However I don't think we can do the same for the OO design, as others in my team simply don't have enough expertise for that. Hence was my question: where do I start? I am not a new to OO design, but since I haven't had enough of relevant practice for a long time - I would need to kick start from a some book perhaps?
    – PeterT
    Sep 6, 2012 at 13:34
  • Have you been developing all the time since you read those books? I.e. have you been applying your knowledge or your work didn't include design?
    – superM
    Sep 6, 2012 at 13:38
  • @PeterT, Please see the last paragraph I've just added.
    – superM
    Sep 6, 2012 at 13:48
-2

I can detect something from your question:

  1. You seem to think that "improving" software architecture is possible. This is not true. Every modification you're doing can only break the original design idea - the ideas you had years ago were already forgotten and something else replaced them.
  2. What you can do is "try to follow existing architecture." This takes effort to understand and follow it. Should only do such improvements which follow the existing architecture. The architecture gets stronger once people stop inventing new stuff and just follow the existing patterns.
  3. Over time software is going to get more complicated. This can hide the original structure of the software if the new stuff is inventing new patterns.
Improve this answer
4
  • 1
    I fundamentally disagree. Often times there's no time to rewrite mistakes made in the architecture, though attempts to correct them should not be abandoned, that's simply defeatist. Coming up with improved ways of accomplishing that piece of the architecture, and beginning to feed that new approach with any new work to that end will succesfully over time bleed out the old poorly designed route. I have seen this incremental replacement approach work time and again, just like in a house, you must put up new support beams before removing any old ones.
    – Jimmy Hoffa
    Sep 6, 2012 at 20:19
  • Jimmy Hoffa: This is where architecture and design differs. Removing old designs is possible. Removing or replacing architecture elements is not possible simply because they're everywhere and you can never replace them all and keep the software still working. (if the software is small, you only have designs)
    – tp1
    Sep 6, 2012 at 20:26
  • I have successfully seen architecture pieces replaced in large enterprise software. Yes they're everywhere, but slowly; over time, it is possible if you just stop constructing elements in that architecture, and as changes to pieces that touch that are needed you do the swap then. I have seen many people say it can't be done don't bother, and yet I have participated in accomplishing it. It is possible. Of course depending on the size of the system it may not be quick, but wholesale rewrite being the other option and completely inviable as Netscape knows.
    – Jimmy Hoffa
    Sep 6, 2012 at 20:32
  • Jimmy Hoffa: Problem is that to replace architecture element, your replacement needs to work and behave almost exactly the same way as the old stuff. The details can be different, but the architecture is not changing when you subtitute one element.
    – tp1
    Sep 6, 2012 at 20:54

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