Surya Suravarapu's Blog

Ramblings on software and stuff related

Posts Tagged SoftwareDesign

Joel vs UncleBob: Relevance of TDD and SOLID principles

Feb 1

Posted by Surya Suravarapu in SoftwareDevelopment | 1 Comment

This is really a clash of two titans, both of whom I greatly admire -- Joel Spolsky (Joel on software) and Robert Martin (uncle Bob). I follow both of them for many years, their writings, on Twitter, podcasts and so on. Uncle Bob was not so happy about the discussion on Stackoverflow podcast #38 and he responded in kind.

My thoughts:

  • Unit testing is extremely important. Every minute that a developer spends writing a testing is well worth hundreds of minutes he would spend later in the maintenance phase. Having said that, if the concern is whether 100% code coverage is too much? Perhaps it is, determine what gives best bang for your buck and go with that. If the question is whether they are useful at all? Absolutely. Taking the same reason as cited in the podcast -- you have a large code base and now you need to either modify or add new features. Once you make the change:
    • how do you know you are done? I run the unit tests that I wrote for the new functionality and pass them.
    • more importantly, how do I know whether I broke any existing functionality? I run all the tests that I have (assuming I have decent code coverage) and make sure all the tests are passed.
    • unit tests along with the acceptance tests, if run more often, can provide extremely useful information about any deviations from the requirements. Rapid feedback, isn't it one of the core principles of agile?
  • You don't have to follow TDD to the tee, or any methodology for that matter. But the spirit of unit testing, in my opinion, is extremely important to know the health of your code.
  • SOLID principles, as Uncle Bob said, are engineering principles. These principles guide you in building the software that is flexible, maintainable and reusable. This is even more important in agile environments where you develop software in tiny increments.
  • Enough emphasis must be given to code hygiene. With out that, it is just a matter of time that the system gets polluted, and not sure how you can keep the customer happy for long. I agree that the focus should be on the customer and just don't architect or refactor just for the sake of it. Focusing on the customer means -- designing flexible, extensible architecture (using design principles) so that you spend less time in constant-maintenance mode.
  • Another common argument against writing tests is time to market. Goal is to get the software out as quickly into the market as possible, fair enough, but at what cost? As software craftsmen we need to pledge for not shipping shit (must read).

I repeat, I have great regard and respect to both the individuals, and hope Joel can elaborate on some of the points that are discussed in his future podcasts and clear the air.

Tags: , , ,

UML Modeling in Color

Jul 24

Posted by Surya Suravarapu in design, Modeling, UML | 1 Comment

I've been meaning to post about this for a while. I worked on a couple of projects earlier using the 'modeling with color using archetypes' approach. In spite of that, recently I have learnt the value of formal learning. The workshop that I attended recently not only refreshed what I knew about the archetypes and color modeling it has challenged some of the ways of my thinking about domain modeling.

It is so convenient to think about an object in terms of colors, more than colors it is the categories that each color represents --

  • Pink (Moment-interval) -- Represents a moment or interval of time. e.g: a sale, a video rental, an account registration
  • Yellow (Role) -- A way of participating in the above activity. e.g: Cashier, Customer, Manager
  • Blue (Description) -- A catalog like description which classifies objects. e.g: product catalog
  • Green (Party, Place or Thing) -- Something that is uniquely identifiable. e.g: Person, Store, Product

During the modeling sessions each object is to be examined in the above order -- whether the object is Pink? If not, is it Yellow? If not, is it Blue? If not, it is a Green. Pinks form the core classes of the domain model.

Peter Coad's way of modeling with Post-it notes on a flip chart or a white board is fascinating . I think it helps quite a bit in the modeling sessions, trying out to refine and further refine the shape of the model during the discussion process. Once the modeling team feels that it has achieved a reasonable model it can then formally draw it using any UML tool. Tools are not of primary importance here. The key really is to guide your thought process using this proven concept.

There is a very powerful Domain Neutral Component (DNC) that Peter Coad and team came up with (reproduced from Step-10) --



I'm quite sure based on my own personal experience, above domain neutral component works like charm for many domains. At this point, I'm very interested in knowing whether anybody tried this on any domains that didn't work out or felt a bit 'challenged'? One thing is it is going to take some time to master this art. Once you get into it, you can really appreciate the amount of effort that went into this whole concept.

Tags: , ,

OO Design: The Liskov Substitution Principle

Aug 25

Posted by Surya Suravarapu in SoftwareDesign | 2 Comments

If you're an experienced OO developer you should by now know what this principle is. I was having a chat with somebody last week regarding the applicability of this principle in the OO design, especially using Java (which prompted me for this entry).

For starters here is the principle:

"If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T."

In more simple words, it means:

"In class hierarchies, it should be possible to treat a specialized object as if it were a base class object. That is -- if a client is using a reference of the base class, then it should be able to replace the base class with the derived class instance with out affecting any functionality."

To be honest, I was not too keen earlier about some of the book-ish theories and principles. I was attending a training session by ObjectMentor a few years ago, when there was some good discussion in the class about Ms. Liskov's principle. That discussion evoked some curiosity in me and helped to take a fresh look at some of the popular Object Oriented principles.

The discussion topic started off with a question whether a Square is a Rectangle or not? For all practical purposes, in the mathematical world it is but certainly not in the OO world if it has to adhere to the Liskov's Substitution principle. See here for more details on that Squares and Rectangles example (C++) and for a bit more real example.

On a related note, there is one line of thought in the OO arena that Inheritance is one of the most abused concepts in Java. I remember Bruce Eckel mentioning in one of those forum discussions that the design of Java Collections is a possible candidate to fall in to that category. He says that although a Set and a List are containers that hold objects, the similarity ends there and their behaviors are quite different.

This one makes an extreme case of Is Inheritance Necessary. I guess the bottom line here is the emphasis of Composition over Inheritance.

If you're convinced about the principle and the best practice that it emphasizes for the Object Oriented design, for a change read this one. Author suggests that the principle doesn't hold good for Java!

Liskov Substitution principle, although seems simple and straightforward, it would be interesting to know how many applications truly follow the principle.

Tags: ,

Checked vs. Unchecked Exceptions — Never Ending Debate

Aug 11

Posted by Surya Suravarapu in SoftwareDesign | Comments off

Yeah, this is one of the favorite combative topic. Battle lines more often are clearly drawn with staunch supporters for both checked and unchecked exceptions.

Although this TSS post avoided going into the controversial topic the discussion followed was not immune to that!

Found this page in the Sun's tutorial handling the issue very well. Bottom line according to this one ..

"If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception."

If that convinces you, here is the Bruce Eckel's perspective. Towards the end of the page Bruce touches the aspect of exceptions in relation with the size of the projects (and I second that thought from my own experience) ..

"... checked exceptions seem to be helpful for small projects, which is generally the space where we argue the point. However, when projects get large (actually, I've noticed it when they are anything except small), checked exceptions get ungainly and seem to cause problems. I would therefore suggest that the reason checked exceptions seem so compellingly "right" at first is that they have been presented and argued in the realm of small examples."

Tags: ,