From cd6644ea4ddc78597934ab0ef5ba50e3c3daa927 Mon Sep 17 00:00:00 2001 From: Mitja Felicijan Date: Sat, 8 Jul 2023 23:25:41 +0200 Subject: Moved to a simpler SSG --- public/software-development-pitfalls.html | 119 ++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100755 public/software-development-pitfalls.html (limited to 'public/software-development-pitfalls.html') diff --git a/public/software-development-pitfalls.html b/public/software-development-pitfalls.html new file mode 100755 index 0000000..94cc15c --- /dev/null +++ b/public/software-development-pitfalls.html @@ -0,0 +1,119 @@ +Software development and my favorite pitfalls

Software development and my favorite pitfalls

Nov 10, 2015

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.

\ No newline at end of file -- cgit v1.2.3