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 --- .../2015-11-10-software-development-pitfalls.md | 180 --------------------- 1 file changed, 180 deletions(-) delete mode 100644 content/posts/2015-11-10-software-development-pitfalls.md (limited to 'content/posts/2015-11-10-software-development-pitfalls.md') diff --git a/content/posts/2015-11-10-software-development-pitfalls.md b/content/posts/2015-11-10-software-development-pitfalls.md deleted file mode 100644 index b9edd19..0000000 --- a/content/posts/2015-11-10-software-development-pitfalls.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -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. -- cgit v1.2.3