php[architect] November 2018

14 \ November 2018 \ http://www.phparch.com

FEATURE

How to Knock Down Any Project in Ten Steps

Paweł Lewtak

In this article, I’ve collected my experience with failing IT projects along with some

real-life examples and observations. Hopefully, you’ll learn from my mistakes, so

you don’t have to repeat them.

Imagine working as a team member

on an IT project; you have a common

goal, and you want to succeed. You

might wonder why anyone might want

a project to fail. Why would someone

sabotage it? I don’t have the slightest

idea. When we start a new project,

we have the best intentions. We want

to use the latest technology and the

experience gained from previous proj-

ects—make the software perfect, and

the customer satisfied. If we learn

something new along the way, it’s a

bonus. Nobody approaches such proj-

ects with the intention of writing bad

code or creating legacy projects others

will be afraid of working on later. And,

yet, it happens much more often than

we would be willing to admit.

I don’t want you to fear IT projects,

quite the contrary. I hope you will

use this knowledge to avoid the most

common mistakes programmers make

and resolve issues before they spiral out

of control.

1. Lack of Planning

Weeks of programming can save

you hours of planning.

• unknown

Let’s start from the beginning. Your

boss assigns you the new project.

Maybe it will be a long-term project or

a microservice. Regardless of the type

or size of the project, there are two

approaches you can choose.

In the first case, we start writing the

code right away. Regardless of the prob-

lem, we have an idea in the back of our

head for a technological stack. Maybe

it’s something we’re already familiar

with or a set of new tools we haven’t

used yet, but we want to. Regardless, we

start to write the code on the first day.

It’s a great way to lose some time and

create code that may not be suitable for

anything. Sooner rather than later, the

moment will come when you will ask

yourself the question: what did I actu-

ally implement?

And this is the second possible way:

we try to understand the problem and

answer the question of what our appli-

cation should do and what problem it

should solve. Only when we know the

answer can we go to the question of

how to do it. The technology should

be adjusted to the problem, but not the

other way round.

This is one of the most common

mistakes and at the same time the

one that can have the most significant

impact on the success of the project. We

often want to start writing code without

fully planning or understanding the

requirements. Before writing the first

line of code we should understand the

problem we are trying to solve.

Example. We have a simple task: add

one field to the API response. It seems

simple, so we get down to implementa-

tion. It turns out the returned value is

the result of certain business logic. This

logic is slightly different depending

on which version of the API is being

discussed. Without asking basic ques-

tions, it turned out that the work that

was to take an hour and touch two to

three files ended in two days of work

and a dozen or so changed files. Imag-

ine what would happen with a larger

scale of changes.

Even if we already know what we

want to do and how we want to do it,

it is worth it to verify this knowledge

regularly. As Heraclitus said, “the only

constant in life is a change.” It applies to

IT projects as well as to life in general.

2. Inaccurate Estimations

Prediction is difficult, especially

when dealing with the future

–Danish Proverb

The second topic that appears at

the beginning of each project is esti-

mation. This is also the second place

where many mistakes are made, which

can contribute to the failure of the

project. Developers are often uninter-

ested in estimations. A popular saying

among them is “it will be ready when

it’s readyn” However, from a business

point of view, you cannot decide to

invest time and money in a project if

you do not know the estimated cost of

such a project. This can delay the start

of a project significantly. If we do not

know how much the work will cost and

what we will have in terms of software

delivered, no one will want to start

developing such a product.

As developers, we will only think of

a “happy path.” We have the informa-

tion handed to us on a tray; everything

seems clear. We assume that there

will be no errors, everything will be

checked earlier on the test environ-

ment. A mid-level developer, who

is passionate about technology, can

carry out the tasks entrusted to them

on their own. They are responsible,

competent, productive, but also too

optimistic. Such a person will always

underestimate the estimates because

they don’t have enough experience to

know what can go wrong. This leads

to underestimation of tasks. And an

underestimated project is a project that