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. 

Development tips

I've worked in some projects so far and I learned some things that can save you a lot of time even if they sound very expensive. These tips are meant for small/medium size projects, perhaps you can apply them to big projects, but I'm not sure.

1. Revision control system from the beginning.
2. Define your goals and milestones, even without dates.
3. Define what you are going to build, with use cases or user stories, or just use whatever you feel comfortable with.
4. Define an architecture, don't go on without this. The architecture must define the form of the system, not the details.
5. Define the contexts you are going to be working on, this means that you have to separate your project into smaller micro-projects (if it applies).
6. Define your frameworks/libraries stack.
7. Define your project(s) structure, this involves folders and files.
8. Define your automated build scripts, something like Gradle would do it.
9. Think in the tests before the implementation, if it's testable, it's implementable.
10. Use continuous integration from the beginning.
11. Keep you source files small and readable.
12. Periodically check your system and update the architecture if some changes have been made.

I omitted several things, but I consider these the most important from a developer's perspective.

I didn't have this information at the beginning because I was too lazy to read about it, and had to learn it the hard way, by suffering the consequences...

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

SE books you must read: Agile Principles, Patterns, and Practices in C#

As a disclaimer, I'm a Java developer, but this book can't be left aside. If you are a follower of the Clean Code movement this is the right book for you. Perhaps the most 'engineer-oriented' book written by Robert C. Martin and Micah Martin.

It covers several concepts about agile development, design patterns, programming, anti-patterns and some code katas to have fun with.

[ Agile Principles, Patterns, and Practices in C# ]