Software Development Edge - Your best guide into the world of delivering good software in time.

The Software Development Edge – Book Review – Part I

Hear me, I beg. And say thankya, big-big. This one is going to be a hell of long post, but do not worry, you can browse through the cites really fast and get all the essential data you need. My very short summary – go and buy this book, remember (almost) every page, it will do you some good. The software development edge by Joe Marasco should be your holy book, your guidance in the dark realm of leading teams and developing software.

I counted exactly 170 good ideas, worth remembering. Regarding a total count of 370 pages we have a score 170/370 ~ 0.46, which is amazing! It means almost every second page you’ll encounter contains something useful.

As you might guess in my book summary I’ll have to cover over 185 pages of ideas. Since it would take too long to release a complete overview at once I decided to split it up in four parts, each covering around 100 pages of text. The first one ends exactly at page number 100.

For now, here we go – book’s best points, no cites but rephrases:

General

Spend a lot of time talking to your developers, get familiar with details and problems.

Worst combination possible – keenness absence and sloppy management. Mostly, it will lead to programs that don’t work and if they do, not very well.

If you happen to be the team leader, do not easily yield to your superior (of course you should listen and give in in most of the times, but not easily, because your superiors may suggest (due to their unknowingness) unreasonable demands.

Your iterative approach to solving problems: observe, listen, empathize, synthesize, testing, write down.
Observe – look around you. What’s happening? Where could be the source of a problem or maybe it’s symptoms?
Listen – after you’ve located the problem, talk to people and listen to their opinion. Talk less, write more.
Empathize – the clear difference is here to “listen” – while empathizing you not only collect objective data, but also give subjective feedback.
Synthesize – now put all parts together: your objective data while observing and listening, emotional aspects while empathizing, your box of tools for solving problems (should be mostly your experience). The result – a possible approach for the given problem – should be put out to test.
Write down – now you should write down everything that occurs while your approach is doing it’s job. If you don’t do it it will become much harder to convince others to accept your approach. Besides, what’s not written down is soon forgotten.

Doubt everything. Check every partial solution.

In every big project someone, who is on his/her own is a potential danger. However you shouldn’t throw all people in one big basket. Create as little teams as possible with as little members as possible. Four groups three or four members each may be way more productive than an horde of 50 employees.

Sooner or later every leader will have to make choices. If your team members were chosen correctly they will accept your decision because having one is better, than none decision at all. However it doesn’t mean that you are free to come up with any crap idea – you still need to analyze give situation. The only thing to avoid is to be paralyzed.

Goals

The mountain top – the end of your project – should always be the main goal. Everything that hinders you and your team on the way up must be cut off.

On the other hand climbing up in real life is just the half of it, you also need to come down. This can be compared with supporting your existing project – a successful one can be completed and then supported over a long period of time.

Why projects fail

Nonrealistic time schedule

Too many team members, team contains a lot of mediocre developers compared to the best ones.

Neverending stories projects lasting so long, that all requirements change multiple times.

Ignore first iterations’ results. No analyze and change after seeing them.

Lack of clear goal, understandable by everyone

What can lead to success

Small, but smart plan with few details is more effective than plan overloaded with details

Clear your work before requirements change

Correct your movement’s vector (use small iterations) on the fly

Durability – extraordinary peak strength means nothing on the long term

Concentration – your team don’t lose sight of the goal

Management

Don’t hire high skilled people to involve them in trivialities.

Main point of every task should be a client’s problem. Even more important is for your product to generate additional value for your customer (by solving his problems).

Best leaders can project their sense of goal to others – by giving them a good example. Managers make sure that this goal is achieved. Best people out there unit qualities of leaders and managers.

Take care of every small problem in time. Even smallest problems tend to grow massively. This leads to two kinds of bad managers – the “ostrich” ones, who won’t see the problem and the “lazy” guys, who will postpone everything until it’s too late. Don’t be one of them, problems don’t disappear magically.

Do not let you lead easily. Always remember – your goal is to solve a problem, achieve some result, not to make you most popular and well-liked guy in the department.

Don’t panic. Seriously. Be solid as rock. Every crisis will be over, your duty is to participate in solving this crisis, not in overreacting. Be an example for everyone else (rock-solid).

Laugh. Even when facing dumbest customer’s demand, better laugh about it, do it, forget it than making drama.

Teams forgive their managers a lot of things, but laziness, incompetence, lack of reward for efforts and lack of humor are not among them.

Trust your instincts – if you are really feeling uncomfortable with something, trust your inner self, most likely you’ll turn our being right (this also means do not hire people who will make you uncomfortable – in exceptional cases it might be worth the risk).

Developing software

Goals are most likely not where they meant to be. Often because at the beginning the technical requirements are not quite clear und well understood.

During the process people will make mistakes.

Your goal is a moving one.

A good manager will always make a lot of little steps rather than few big ones. This allows to shorten the overall distance because after one misstep you haven’t travelled a big distance and after a dozen steps your next one will most likely be close to optimal.

Do not start with easiest problems. By doing so you’re digging your own grave. Your team won’t bother with upcoming possible risks. Even the easiest task will grow big (there is always room for improvement). This leads to scarcity of time for the real challenge and to one further problem – explaining that you need more time doing the most difficult part, covering the biggest risks is much easier to your superiors than begging for more time because your team was wasting it.

Iterative approach forces you to apply all lessons learned from this project (all previous iterations) to all upcoming iterations of the same project.

 

Published by

Anton

Hello! My name is Anton. I am a passionate project manager who loves digging deep into code. You can check my Github and CodeEval. Hopefully my thoughts on management can lead you to one or another good idea.