Apparently, it is an ongoing theme that I write these post with a growing deficit of sleep. With that in mind, lets dig into the rambling of an exhausted programmer with Agile Principle 10.
Principle 10: Simplicity–the art of maximizing the amount
https://agilemanifesto.org/principles.html
of work not done–is essential.
Since you have been all surprises recently. What do you think of Agile Principle 10?
I think it is stupid. Not the idea of lets maximize how much we can do by keeping things simple but the lack of context. It just kind of makes it useless. I don’t know many devs that spend their time trying to be slow. Nor have I run into too many people that want to make complex things.
In my experience, complexity comes from black boxes of knowledge about the tools or project. The constant adjustments caused by this missing information, mess with the design of the project. Then we get some more adjustments. Finally we adjust your adjustments. Most of the time it is one of a couple of things that cause this complexity generating cycle of adjustments.
The ideas is not fully formed.
The people paying the bills don’t want to waste time on unproductive design work. Coding equals work. Design is grab ass.
Speed being the single most important criteria in the project.
The end result are black boxes. Let me tell you, it is an irritating way to develop code in that kind of environment.
All that stabbing in the dark tends to put holes in things that are really ugly.
So you think it is stupid and you agree with the statement?
I guess. Can’t a guy get a break from the torment, Alfred?
There was a project back a while ago that was a horrible. Lets hang up the shingle because this project sucks so bad, I want to just become a welfare queen, awful. It was anything but simplicity. There was constant rewrites as their finished system kept having evolving APIs every night.
There were so many black boxes int he project that I never figured out if the existing employees were messing with me, having the plan changed on things they thought we finished or were just bad at their job. The business owner wanted done fast. It did not help the business owner thought he was a great project manager. He ranked last on my list of project managers in my career. What he lacked in competency and patience, he made up in belief in himself.
The black boxes where foundational element of the project. The person who was working on before, threaten to quit if she could not stop working with the two on staff developers. This is not a good sign. She is pretty chill and quite frankly, probably a better web developer than I am. I had a bad feeling on it and I did it for the worst reason possible. A friend asked me to do it.
That favor almost ended my business as I would rather work the drive through then deal with that cast of Stoogies again. I probably left 50k on the table to get away from these people. As a side note, I suspect it was so abusive for her, that she stopped taking jobs from our project hunter service. I have received all her projects since that event because she was too busy.
Another black box was when or if the customer would pay their bill. They used our accounts receivables as leverage against us. If you consult, call the customer out on it. We did and he admitted that was what he was doing because he had the power. The lesson from that was that if your client does that shit. Fire them, they are not worth the money.
After the torment that was working with Tweedledee and Tweedledum, the website’s minimal viable product delivered on time. After the approval of the work, I fired the customer. I have little tolerance for abusive, pain in the asses, who are bad at paying their bills. Often they are one and the same.
So back to simplicity and the whole Agile Principle 10 thing?
If you want simplicity there are several things you can do.
Eliminate black boxes. Be careful about projects that have too many of them. Treat the black boxes with respect. They can derail a project at worst and complicate it at best.
If your client has some issues with focus as they bounce on to version 54 before the code of version 1 is complete. Use wire frames, the act of writing things down forces people to actually think. It also makes the vision easier to sell. Establish the minimum viable product.
Don’t be afraid of libraries. Especially ones from major open source or major IT companies. They can save you a bunch of work.
Finally nothing bring simple code better than clarity of the project’s vision so talk to your business owner early and often.