The mythical man month - the tar pit

Preface

It's been a while since I wrote something, work, university and life in general have kept me busy enough to forget that from time to time it is required for me to spare some words in any kind of medium. Just for the fun of doing it.

Then I just started reading the book The Mythical Man Month by Frederick P. Brooks because I found in many places that it is a mandatory reading for software development in general and I started reading it to find out what it has on it.

Initially I was just a little bit skeptic about the fact that a book so old (in software-related terms) could have some content for me to be interested.

But after finishing the first chapter I realized that this is not just only a very interesting book, but an invaluable source of data, techniques, practices and tales about how software engineering has been done in the words of the great Frederick P. Brook.

So as I identify this book as something I want to remember, I'm going to write down my thoughts in a chapter-by-chapter basis, pointing the things I have experienced related to them.

The Tar Pit

In this chapter its author identifies that in many senses large systems development can be compared to a huge tar pit where incredibly strong creatures have found their death. 

It defines in a very interesting way programming systems product as:

• A program, a software product that can be developed by small teams, a simple application (i.e. cat).
• A programming product, a software product that can be extended or used for the programming of other systems, a library component (i.e. SQLite).
• A programming system, collection of interacting programming products, I identify it as a basic operating system (i.e. Minix).
• A programming system product, a collection of interacting programming products that could used and extended by anybody, I identify it as a complete operating system (i.e. Linux)

Based on such classification it describes how systems programming is a craft that has joys and woes inherent of software development, that is impossible to develop something without having limited resources, budget, time and collaboration. But when ones get things done you can express with great honor that you survived the pit. 

Domain driven semantics

If you are a programmer, you have dealt with persistence layers in many senses:

• RDBMS systems
• File systems
• Remote storage
• Just memory...

And if you are a programmer, you know that all those persistence layers have to be abstracted from the application's business logic. There are several techniques to achieve this:

• Data Access Objects
• Mappers
• Object Relational Mapping
• CQRS pattern

All those techniques wrap your data from the persistence source you are using, because your application should have its own 'language'.

Why?

Because each application is meant to solve a specific problem (or a set of problems), and that problem has a domain, and that domain will be used as basis during the development/maintenance phases. During these phases you might have different people working with the same code. So, the developers will need to understand what they are modifying in order to add/remove/fix specific parts of the system.

This is the point where documentation and comments become important, I also take a deep look at the context applied to the programming, I mean, class names, attribute identifiers, method names, etc.

All these things give the source code a meaning, what can you say from this?

and what about this?

which one is more verbose? which one has more meaning? which one would you prefer to have in your source code?

Even though the first chunk of code uses JPA, it is verbose enough, the second one really does its job, you don't need to know whether you are using a database or not and it is really easy to read, if you want to modify a condition or change the behavior you just go to the specific method, and that's it! 

Generic actions model

Have you ever tried to install something in a Linux distribution and have struggled with a dependency manager? such as DEB, RPM, PACMAN?

Dependency graph

I have a love/hate relationship with these models, sometimes they save my day, but some others are really, but really hard to deal with.

In software development you will find such scenarios, where you have something to do, and that thing will require another thing... and so on.

I mapped this model about a generic rule-dependency model:

• Action: Component doing some kind of work. All the dependencies are one-side oriente, and each dependency can have many other dependencies.
• ActionsRepository: A collection of sorted actions by any kind of criteria. Normally not allowing duplicated actions.
• ActionsExecutor: Component in charge of iterate and execute the actions.

When you don't need a framework

I've been developing applications for a short time, from small to medium size codebases with many different features, requirements and environments. For all these applications I've always found the issue about the frameworks, sometimes this discussion takes days, or even weeks if the people involved is very passionate about Rails, Hibernate, JSF, CDI, and some others.

Mostly the discussions tend to be related to the benefits a framework can give us: speed, conventions, less coding, design improvements, being cool....

And for some projects the right frameworks have been a blessing, improving the developer experience and reducing development effort. But that's not always the case, because sometimes the frameworks can lead you to think that 'their' way to do it is the 'right' way.

'Their' way to do it can be 'right' for their intentions, but your application is not meant to be based on their intentions, but your customer ones. A framework should not define how your application is structured, how your business logic is wired, and not even how your tests are written.

I've always struggled with testing on a framework, because most of the times the requirements for its setup are so large, that makes you feel sick. And it's even worse if you are tied to certain technology because your customer has bought the 'sweetest' license in the market.

But well, here's my summary about frameworks:

Advantages

• Speed, not always, but a lot of frameworks are performance-oriented.
• Support, if it's open source, you will have a lot of it.
• DRY, yeah, you don't reinvent the wheel.
• Convention over configuration, very powerful, and saves lots of efforts.

Disadvantages

• With bad design decisions, you can marry your code with a framework, and that marriage is an ugly one
• Performance, as said, not all frameworks are performance-oriented.
• Test difficulty, you mean that I have to setup the entire framework stack in order to test a single operation?

When to use them

•  It's rare to find a reason not to use a framework, I would say that the question is not 'when to use a framework?', but 'how my application should be designed in order to be framework-agnostic?'.

When not to use them, or at least think twice before using them

• When its usage doesn't give you any advantages
• When you have a 'contractual' boundary with it
• When your team dislikes it
• When your tests take more than 10 seconds to setup its environment
• When the framework itself is untestable

Based on: Architecture, the lost years - Robert C. Martin

Liquibase: Database change management

When you are developing an application, is almost sure that you will have to deal with a relational database system. And if you are developing with a 'refactoring' point of view, your database structure will change from time to time.

In many situations these changes have to be tracked and automatically applied for the different environments (development, integration, production) and I bet you are currently doing that manually, updating scripts and wiping databases back and forth.

This is no longer the case for me, a while ago I started using DBUnit for managing my database data changes, but as the development moved forward, the database structure changed as well. So we started looking for a tool that could simplify our lives.

Guess where we found it, in the DBUnit FAQ page, they even recommend it!. The tool is Liquibase, a java-based application that uses XML changesets to handle the database modifications, it works smoothly and support almost all productive database systems. It might be a little bit hard in the beginning, but it is worth it.

Software Architecture, lessons learned

There are very good developers, that can create great products out of nowhere without thinking too much. Well, I'm not one of those, it takes me a while to get the right idea, and several times I had to throw everything I've bee working on and start from scratch.

But even in situations like these, there are some things you learn from time to time.

Minimalism

This is something I learned from Robert Martin's Clean Code (but I think it just takes common sense). When your components are not meaningful and don't relate to each other in an almost 'natural' way, you need to refactor it. Your system might work beautifully, but your internal structure is a mess and it will create problems to future maintainers.

Keep it simple

Complex design leads to complex code, complex code leads to complex tests, and the mess has now started. The design has to be as simplest as possible, and your code has to be consequent to this. And by code I mean production code and the test units related, because that it's maintainable code too!. Check KISS Principle on Wikipedia.
 

Life time

System components and inner objects must follow the natural law, die. While shorter your objects live the better, are easier to handle, to test, and to refactor. Including memory usage improvements, as your objects are created and dropped as soon as they are used. This is something I find very useful, and I discovered by playing around with Google's Guice project.

Patterns

Check the patterns once a while, review your architecture, don't reinvent the wheel. There are several good references for it, but I tend to enjoy Martin Fowler's patterns (and the articles describing them). Have a look at the LMAX architecture.

Which pattern is this?

I've been working in a component with some singularities, one of them is his incremental behavior. To make it clear: When a feature is almost complete (or completed), some other features arise.

This is really annoying if you have implemented everything for an specific use (never do this, I've learned in the bad way) if needs to be changed to work with the new stuff.

One of the things that I needed to do is to create/fill/validate different objects; I started thinking: "This is easy, let's do a mapper for each one of them". So far so good, then another type of object to work with.... shit, create more mappers, modify logic...

I started thinking "I'm doing this over and over, why am I so stupid?, use interfaces, builders, factories, simplify the problem... moron". I realized that the validation/filling... logic was the same, so the things that are different  needed to be isolated: the mappers (I don't know the real name).

With a little of work, I did this:

public interface Initializer<Source,Target>{
     // initializes the Target object using the Source as data provider 
     Target initializeThis(Source source, Target reference);
}

Then my object creator is:

public class ObjectCreator<Car> implements Creator{
    public Car prepareObject(){
        Info info= readInfo();
        Initializer init = InitializerFactory.newInitializer(Car.class,Info.class);
        return init.initializeThis(new Car(),info);        
    }
}

The logic doesn't changes, just use the proper Creator, and that's it. But I don't really know if this is a pattern, or an anti-pattern, or whatever.