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. 

Why I dislike the term 'Agile/Software/Practices Evangelist'

As software developers we often see these kind of adjectives on someone's profile, normally on LinkedIn or some resumes you get from time to time. I dislike this term, not because of the history behind it nor the intention it tries to give, but because of its meaning:

"the practice of relaying information about a particular set of beliefs to others with the object of conversion" - Wikipedia

The problem raises with the word 'beliefs', when working on systems and organizations, you shouldn't rely on beliefs, beliefs can or can't have proofs. You should rely in things that have a background or some basis that you can use in an argument.

If you are, let's say, an Agile Evangelist, you've already lost me. Because you described that you do what you do not because it is the best way you found of doing it, it is just because you believe it might be.

We, as people who work building reliable systems, should be careful about using something that doesn't have a valid argument beyond a belief, we should be able to say 'We chose this process because it has proven to be at least 50% more efficient'.

Argue about what you do, be critic of what you use, think and analyze, don't follow fashion, follow ideas with sustainable arguments.

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...

TDD helps you find the way...when you are lost

There are times when you start a project, and you understand exactly what it has to do, you know the inputs, and the outputs. You might know even some of the inner logic in between, but you can't get your head around it.

That is, not to know how to do it. Not to know where to start from and where you are targeting to. This problem arises almost always you are dealing with something new, something you have never done before and perhaps have ever seen.

That's been the case for me in some projects I've worked on, some times it took me a while to get the right idea, after hours/days/weeks struggling with the logic and the results verification.

In my first days, I would do the verifications by hand, a tedious process where I would reply all the steps in order to verify that everything is working as expected. If something got broken, I would fix it and then start the tedious process again.

This was painful, and exhausting, that loop trapped me for months. I thought that someone else would have found a way to get this done without that much effort. Then I started reading about testing techniques, leading to best practices, disciplines....a hole world of professionalism and engineering is out there, you just have to seek it.

The concept that fit for my problems was TDD, it applied for the situations I experienced and its scope is what I was looking for, the cycle looks like this:

with automated tests and frameworks, and the most important....you know that you are done when you can't think on more tests to write!!!

I strongly suggest you to give it a try, it's a discipline that will make you a better, more responsible developer, and also will provide you a way of building targeted products in a safe way.