When you hear the word "Software methodology" then you are guaranteed to end up with crap. Very expensive crap.
The word '"Software methodology" is actually used by people that have no understanding what software development means and by teachers that wants to sell yet another useless very expensive courses to people that are below average.
No one believes me but I am going to repeat it again. one "good" developer will can perform the same productive outcome as a complete SCRUM team. One good developer will work very optimized, no slow down by other idiot developers, useless meetings, useless debates and discussion and still create code that will be future proof and agile. He will create future proof because he realizes very well that he is going to eat his own shit and that bug he ignored will smack him back in his face. He will create better code because no one else will save his ass when the deployment fails.
Good solutions are always written optimized for what the company needs. A generic solution will always produce bad results.
I posted this hoping for some good curmudgeon commentary - as I know the subject can be pretty divisive and some folks can get pretty passionate about the methodology.
I hired programmers. I can program - but I suck at it. No, really... You don't want me coding anything (some day, remind me to tell you how I once wrote the most insecure Perl script ever written - and it's still sometimes seen to this very day) that you have to use in production.
My eventual method doesn't have a name. I guess, I could call it, "Get the fuck out of the way." It's pretty easy, actually.
Give clear directions - by explaining what you want, not how they should do it. Tell them what problems you need to have solved.
Buy them the tools they ask for, and not the tools the vendor recommends. Back then, things like proprietary languages and compilers were the norm.
Wait a week before asking for an ETA. Any ETA given before that is a bullshit, meaningless date. They simply don't know how long it will take.
Let them organize themselves. This way, you only have to communicate directions to a few of them. They're smart, they'll figure it out.
Get the fuck out of the way. You hired them to do a job. If you were smart, you hired good programmers. Get out of their way and let them do their job.
Remember, you hired them to do things you could not do. If you could do them, you'd have not needed to hire them.
Again, get out of their way. Encourage them to come to you with problems and requests for resources. Solve those, as best as you can. Let them do the programming that you'd hired them to do.
Get out of the way. They have lives and need to lead them. They don't need an ass in the chair all day, they only need to get the job done. Who cares where they work from, so long as the job is done?
There you go... That's more a management strategy but, frankly, I don't much care how they do it - so long as they get it done. I care(d) more about results than about quantity. You hired smart people. Get the fuck out of their way and let them do smart people things.
These are lessons learned. I actually never took a single business management class, which is probably for the best. At first, I tried micromanaging and I also would try to help. "Oh, they're behind schedule. I can help!" No, no I can't. Well, I can, but it's not very productive or helpful. Show them the math you want, show them the weights you want applied, and let them figure out how to do it programatically.
This only works with good developers. Those developers most enterprises will refuse to hire because they fail the bingo word tests.
Now how do you know that you have a good developer? Easy give him failed projects and see if he can bring order into the chaos without rewriting from scratch!! and make projects function even if they are still buggy as hell.
The second clue that you have a good developer is when the code that was in pure chaos becomes readable and easy to alter. Good developer can reverse engineer the code by only seeing the code and modify it in such a way that it behaves exactly the same as before but more readable.
So the Kanban approach is basically splitting up all of the work into the small tasks (i. e. issue, bug, feature), organizing them into different cards, prioritizing them accordingly, and moving them through the one workflow like, “to do -> in progress -> done.”
This sucks in real development. It only functions as a theoretical model but the failure here is that software is built onto layers and layers of buggy code, making your basis unpredictable.
The failure here is not to recognize that not everything can be quantized and locked into "tasks". Not all developers are equal!
The failure here is not to recognize that you will have idiots in your team that will damage your hard work.
The failure here is that your team won't understand what you are doing and will fight you. They will stick to their methodology no matter what damaging the complete project even further.
The failure here is not to recognize that after the sprint what you get is what you deploy even if it is buggy as hell because time's up!
The failure here is not to recognize that some parts of the code must be slowly modified over very long times that does not fit into a task. You modify them when you have time and when you have rasher sharp focus. You don't modify it because your SCRUM planing says you must.
Bing back productivity! Bring back good code! Bring back creativity! Let the madness called AGILE be thrown in the abyss.
5 comments
0 u/TheBuddha [OP] 02 Jan 2018 20:47
The answer is always AGILE!
I kid, it's not a bad article.
Curmudgeons.
0 u/roznak 02 Jan 2018 22:00
When you hear the word "Software methodology" then you are guaranteed to end up with crap. Very expensive crap.
The word '"Software methodology" is actually used by people that have no understanding what software development means and by teachers that wants to sell yet another useless very expensive courses to people that are below average.
No one believes me but I am going to repeat it again. one "good" developer will can perform the same productive outcome as a complete SCRUM team. One good developer will work very optimized, no slow down by other idiot developers, useless meetings, useless debates and discussion and still create code that will be future proof and agile. He will create future proof because he realizes very well that he is going to eat his own shit and that bug he ignored will smack him back in his face. He will create better code because no one else will save his ass when the deployment fails.
Good solutions are always written optimized for what the company needs. A generic solution will always produce bad results.
0 u/TheBuddha [OP] 02 Jan 2018 22:14
giggles
I posted this hoping for some good curmudgeon commentary - as I know the subject can be pretty divisive and some folks can get pretty passionate about the methodology.
I hired programmers. I can program - but I suck at it. No, really... You don't want me coding anything (some day, remind me to tell you how I once wrote the most insecure Perl script ever written - and it's still sometimes seen to this very day) that you have to use in production.
My eventual method doesn't have a name. I guess, I could call it, "Get the fuck out of the way." It's pretty easy, actually.
There you go... That's more a management strategy but, frankly, I don't much care how they do it - so long as they get it done. I care(d) more about results than about quantity. You hired smart people. Get the fuck out of their way and let them do smart people things.
These are lessons learned. I actually never took a single business management class, which is probably for the best. At first, I tried micromanaging and I also would try to help. "Oh, they're behind schedule. I can help!" No, no I can't. Well, I can, but it's not very productive or helpful. Show them the math you want, show them the weights you want applied, and let them figure out how to do it programatically.
0 u/roznak 02 Jan 2018 22:52
This only works with good developers. Those developers most enterprises will refuse to hire because they fail the bingo word tests.
Now how do you know that you have a good developer? Easy give him failed projects and see if he can bring order into the chaos without rewriting from scratch!! and make projects function even if they are still buggy as hell.
The second clue that you have a good developer is when the code that was in pure chaos becomes readable and easy to alter. Good developer can reverse engineer the code by only seeing the code and modify it in such a way that it behaves exactly the same as before but more readable.
0 u/roznak 02 Jan 2018 22:13
This sucks in real development. It only functions as a theoretical model but the failure here is that software is built onto layers and layers of buggy code, making your basis unpredictable.
Bing back productivity! Bring back good code! Bring back creativity! Let the madness called AGILE be thrown in the abyss.