Before the Project

In this post I will be talking about David Thomas and Andrew Hunts’ The Pragmatic Programmer book, specifically Chapter 8, in this chapter we will talk about what to do before a project.

The Requirements Pit

When start any project, we need to define first what we want to achieve or solve with it. The requirements phase is crucial, in the early days, computer were not as flexible as today. So, back in the day, requirements needed to be really specific and not change overtime because of the technology back then. Today, this is not the case, requirements change everyday and is really common now. Our job as programmers is prepare for these changes but also, one of our greatest abilities is getting the requirements out of our clients. No one know what they want exactly, they change their mind in a matter of seconds and until they see their ideas projected in the project they will know if they like it or not.

We programmers help people understand what they want. We will sit in our clients chair and ask questions to help them see what they want. Our clients know what they want, but they don’t know how to express it, that’s why we make certain questions, edge cases and stuff they never thought about. Also, there are prototypes and that will help us create a feedback loop in which the client sees the progress and has a better idea of what the en product will be and can guide us to the correct path. Sometimes what we develop achieves the client’s need or goal, but not in the way they wanted it. An example is the mix board for electronic music, before that existed there was already a device that solved that problem but the way it was handled didn’t convinced the musicians even though it got the job done. After several feedback loops and a correct requirements process, finally the engineers and musicians could connects a developed the mix board which is a great success.

The requirements need to be documented for future reference and to keep track of the project, however, this document is only for the developers, if you give them access to this document they will likely ignore it because is very technical and don’t care about all of that low level definition. The document is for planning and be careful to not over specify the requirements, requirements are not architecture. Requirements are not design or user interface. Requirements are need and that’s it.

Solving Impossible Puzzles

There are many problems that will present to us in the future while coding. Every time we face them we need to keep in mind certain concepts. First of all, don’t panic. Panic is our worst enemy in these situations, it blocks our brain and we can’t think straight and will get distracted by other ideas that have nothing to do with the problem at hand.

When facing the problem, there’s a common phrase that goes “Think outside the box”, this is true to a certain point, but before thinking outside the box we need to find this box, so we know how to get outside of it. Many problems have simple solutions that we don’t think of because we think they are too dumb. But, we all know the Trojan Horse and we can all agree that the plan of introducing the troops through the main gate sounded like a really stupid idea, but at the end it was the greatest method. Same applies to coding. When you want to find the solution to something you should always think of all solutions and test them, not just say this will never work, prove it will not work and sometimes you will get a surprise when a crazy idea worked. In this process we should try everything we think of and let our brain get inspired and think of all the ways it can as crazy as they sound it doesn’t matter.

Working Together

This is a key concept, in the book they suggest to never got alone into the code, there’s always help at our hands. Pair programming is one of the most popular ways of collaborating to solve hard problems, it is very useful and proves to be very effective, it consists of pairing with another developers and have a session of an hour or so to solve certain task or problem. There is also another technique which is mob programming. It consists of joining with more people not just two, and also these people doesn’t have to necessarily be developers, they can be users, project sponsors, and testers.

And as with all collaboration, you need to manage the human aspects of it as well as the technical. Here are just a few tips to get started:

• Build the code, not your ego. It’s not about who’s brightest; we all have our moments, good and bad.
• Start small. Mob with only 4–5 people, or start with just a few pairs, in short sessions.
• Criticize the code, not the person. “Let’s look at this block” sounds much better than “you’re wrong.”
• Listen and try to understand others’ viewpoints. Different isn’t wrong.
• Conduct frequent retrospectives to try and improve for next time.

The Essence of Agility

Agile is not a noun, agile is how you do things. Agility is your style, not you. Many companies have started to make things a bit complex with job titles that make no difference and also a lot of processes that are not needed in agile development. Many people have lost sight of the true meaning of agility, and we would like to see folks return to the basics.

Remember the values from the manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools-
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Whenever someone says “do this, and you’ll be agile,” they are wrong. By definition. Because agility, both in the physical world and in software development, is all about responding to change, responding to the unknowns you encounter after you set out.

So here’s our recipe for working in an agile way:

1. Work out where you are.
2. Make the smallest meaningful step towards where you want to be.
3. Evaluate where you end up, and fix anything you broke.