aboutsummaryrefslogtreecommitdiff
path: root/content/posts/2015-11-10-software-development-pitfalls.md
blob: 57e9736aecb4b0b4491eb6334fe4ade44c4a4f2a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
---
title: Software development and my favorite pitfalls
url: software-development-pitfalls.html
date: 2015-11-10T12:00:00+02:00
draft: false
---

Over the years I had the privilege to work on some very excited projects both 
in software development field and also in electronics field and every experience 
taught me some invaluable lessons about how NOT TO approach development. And 
through this post I will try to point out some absurd, outdated techniques I 
find the most annoying and damaging during a development cycle. There will be 
swearing because this topic really gets on my nerves and I never coherently 
tried to explain them in writing. So if I get heated up, please bear with me.

As new methods of project management are emerging, underlying processes still 
stay old and outdated. This is mainly because we as people are unable to 
completely shift away from these approaches.

I was always struggling with communication, and many times that cost me a 
relationship or two because I was not on the ball all the time. Through every 
experience, I became more convinced that I am the problem and never ever 
doubted that the problem may be that communication never evolved a single step 
from emails. And if you think for a second, not many things have changed around 
this topic. We just have different representations of email (message boards, 
chats, project management tools). And I believe this is the real issue we are
facing now.

There are many articles written about hyper connectivity and the effects that 
are a direct result of it. But mainstream does nothing towards it. We are just 
putting out fires, and we do nothing to prevent it. I am certain this will be 
a major source of grief in coming years. And what we all can do to avoid this 
is to change our mindset and experiment on our communication skills, 
development approaches. We need to maximize possible output that a person can 
give. And to achieve this we need to listen to them, encourage them. I know 
that not everybody is a naturally born leader, but with enough practice and 
encouragement they also can become active participants in leadership.

There are many talks now about methodologies such as Scrum, Kanban, Cleanroom 
and they all fucking piss me of :). These are all boxes that imprison people 
and take away their freedom of thought. This is a straightforward 
mindfuck / amputation of creativity.

Let me list a couple of things that I find really destructive and bad for a 
project and in a long run company.

## Ping emails

Ping emails are emails you have to write as soon as you receive an email. Its 
sole purpose is to inform the sender that you received their email, and you 
are working on it. Its result is only to calm down the sender that their task 
is being dealt with. It’s intent basically is, I did my job by sending you 
this email, so I am on clear grounds. I categorize this email as fuck you email.
This is one of the most irritating types of emails I need to write. This is 
the ultimate control freak show you can experience, and it gives the sender a 
false feeling of control. Newsflash: We do not live in 1982 where there was a 
possibility that email never reached the destination. I really hate this from 
the bottom of my heart.

They should be like: “Yes, I am fucking alive, and I am at your service my 
leash!”. I guess if I would reply like this, I wouldn’t have to write any 
more of this kind of messages.

## Everybody is a project manager

Well, this is a tough one. I noticed that as soon as you let people to give 
their suggestions, you are basically screwed. There is a truth in the saying: 
“Give low expectations and deliver little more than you promised.”.

People tend to take a role of a manager as soon as they are presented with an 
opportunity. And by getting angry at them, you only provoke yourself. They are 
not at fault. You just need to tell them they are only giving suggestions and 
not tasks at the beginning and everything will be alright. But if you give 
them a feeling that they are in control, you will have immense problems 
explaining why their features are not in current release.

Project mission must be always leading project requirements and any deviation 
from it will result in major project butchering. And by this, I mean that the 
project will get its own path, and you will be left with half done software 
that helps nobody. Clear mission goals and clean execution will allow you to 
develop software will clear intent.

## We are never wrong

I find this type of arrogance the worst. We must always conduct ourselves that
we are infallible and cannot make mistakes. As soon as a procedure or process 
is established, there is no room for changes or improvements. This is the most 
idiotic thing someone can say of think. I think that processes need to involve
and change over time. This is imperative and need to have in your organization 
if you want to improve and develop company. We all need to grow balls and change 
everything in order to adapt to current situations. Being a prisoner of 
predefined processes kills creativity.

I am constantly trying new software for project managing and communication. 
I believe every team has its own dynamic, and it needs to be discovered 
organically and naturally through many experiments. By putting the team in a 
box, you are amputating their creativity and therefore minimizing their 
potential. But if you talk to an executive, you will mainly find archetypical 
thinking and a strong need to compartmentalize everything from business 
processes to resource management. And this type of management that often 
displays micromanagement techniques only works for short periods (couple of 
years) and then employees either leave the company or become basically retarded 
drones on autopilot.

## Micromanaging

This basically implies that everybody on the team is an idiot who needs to 
have a to-do list that they cannot write themselves. How about spoon-feeding 
the team at launch because besides the team leader, everybody must be a 
retarded idiot at best?

I prefer milestones as they give developers much more freedom and creativity 
in developing and not waste their time checking some bizarre to-do list that 
was not even thought through. Projects constantly change throughout the 
development cycle, and all you are left at the end is a list of unchecked tasks 
and the wrath of management why they are not completed. Best WTF moment!

## Human contact — no need for it!

We are vigorously trying to eliminate physical contact by replacing short 
meetings with software, with no regards that we are not machines. Many times 
a simple 5-min meeting at morning can solve most of the problems. In rapid 
development, short bursts of man to man communication is possibly the best 
way to go.

We now have all this software available, and all what we get out of it is a 
giant clusterfuck. An obstacle and not a solution. So, why we still use them?

## MVP is killing innovation

Many will disagree with me on this one, but I stand strong by this statement. 
What I noticed in my experience that all this buzz words around us only 
mislead and capture us in a circle of solving issues that already have a 
solution, but we are unable to see it without using some fancy word for it.

The toughest thing to do for a developer is to minimize requirements. Well, 
this is though only for bad developers. Yes, I said it. There are many types 
of developers out there. And those unable to minimize feature scope are the 
ones you don’t need on your team. Their only goal is to solve problems that 
exist only in their heads. And then you have to argue with them, and waste 
energy on them, instead of developing your awesome product. They are a cancer 
and I suggest you cut them off.

MVP as an idea is great, but sadly people don’t understand underlying 
philosophy, and they spent too much time focusing and fixating on something 
that every sane person with normal IQ will understand without some made up 
acronym. And the result is a lot of talking and barely no execution.

Well, MVP is not directly killing innovation, but stupid people do when they 
try to understand it.

## Pressure wasteland

You must never allow to be pressured into confirming a deadline if you are not 
confident. We often feel a need that we are in service of others, which is 
true to some extent. But it is also true that others are in service to us to 
some extent. And we forget this all the time. We are all pressured all the 
time to make decisions just to calm other people down. And when they leave 
your office you experience WTF moment :) How the hell did they manage to 
fuck me up again?

People need to realize that the more pressure you put on somebody, the less 
they will be able to do. So 5-min update email requests will only resolve in 
mental breakdown and inability to work that day. Constant poking is probably 
the only thing I lose my mind instantly. For all you that are doing this: 
“Stop bothering us with your insecurities and let us do our job. We will do 
it quicker and better without you breathing down our necks.”

If this happens to me, I end up with no energy at the end. Don’t you get it?
You will get much more from and out of me if you ask me like a human person 
and not your personal butler. On a long run, you are destroying your 
relationships and nobody would want to work with you. Your schizophrenic 
approach will damage only you in a long run. Nobody is anybody’s property.

## Conclusion

I am guilty of many things described in this post. And I find it hard sometimes 
to acknowledge this. And I lie to myself and try vigorously to find some 
explanation why I do these things. There is always space for growth. And 
maybe you will also find some of yourself in this post and realize what needs 
to change for you to evolve.