The Pragmatic Programmer EP.9 — Before a project begin

Natnicha R.
CodeX
Published in
4 min readJun 16, 2022

Before you start a project, make sure you have everything you need to implement the project.

Photo by mentatdg on Pixels

Gathering Requirement

Normally, clients have an idea of what they want. But, it’s not exactly what they are looking for. As a result, the pragmatic programmers take on a role of a questioner in order to figure out the exact ones.

The statement of the need of the clients, it’s not the final requirement. In fact, it’s a starting point that allows us to explore what is they really need. Repeatedly getting feedback questions from the statement of their need is what we have to do during gathering requirements. You might even offer to sit next to them so you can observe how they operate. Or, as reality illustrates better than documentation, you may make a prototype to show them. In the end, you will understand what you have to implement for them.

Keep in mind, when they tell us about the policy of their company, for example, junior staff have to get approval from the manager for any request, and managers and up are only allowed to see the evaluation results of junior staff. All of these may be converted to the requirement that anyone who is only granted permission is allowed to do something.

The creation of a glossary or dictionary that lists every definition used in the project will allow users and developers to communicate using the same word.

if users and developers call the same thing by different names or, even worse, refer to different things by the same name. — The Pragmatic Programmers

Solving Hard Problems

When you faced hard problems, here is the way to solve them described in the book below:

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution — The Pragmatic Programmer

This implies that we should consider all possible solutions. Think about all constraints you have. Don’t throw anything away. Because all parts can be included in the solutions.

If you find yourself stuck with the problems for too long or go on the wrong path. Take a break to pause your unconscious brain for a while as I said in The Pragmatic Programmer EP.8 — Things during coding under “Deal with your unconscious mind” topic.

Pair Programming

When we completely work together with our teammates, we commonly apply a pair-programming methodology while implementing.

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. — Wikipedia

Additionally, the writers claimed that

There are many benefits to pair programming. Different people bring different backgrounds and experience, different problem-solving techniques and approaches, and differing levels of focus and attention to any given problem. The developer acting as typist must focus on the low-level details of syntax and coding style, while the other developer is free to consider higher-level issues and scope. — The Pragmatic Programmer

When we encounter more difficult issues, we may use mop-programming, which allows more than two people to work with the same issue. A business analyst, tester, etc., can be one of them. Only one operates a keyboard while the others talk about a problem that is emerging.

Agile development techniques

Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. — Atlassian

In short, agile is how you deal with something. For a pragmatic programmer, we code the software by iteratively gathering and acting with feedback. Here is the agile procedure that the authors refined as follows:

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.

Repeat these steps until you’re done. And use them recursively, at every level of everything you do. — The Pragmatic Programmer

However, we need start with a good design to make it simple to change via decoupling in order to enable the best agile appear.

Thanks to The Pragmatic Programming book for the above knowledge, if you are interested in reading this book, click here for more detail.

--

--

Natnicha R.
CodeX
Writer for

Software Engineer, Backend Designer, Algorithm Developer