Let me set the scene
…at the end the Great day came, you would have had to go live in a couple of hours and the tension and the excitement were tangible. Then…something went wrong. Badly. What happened after it is not so easy to recall, the servers stopped to work and some people started to shout orders, other people started to type on the keyboard frantically or talk at the phone, someone was reporting about an accident in the server’s room, something maybe went on fire.
You were in the room, paralyzed, with the corner of your eye you were sure that someone was climbing over the window and someone else was ready to set himself on fire in the middle of the room before the End.
A terrible silence came upon the room and everyone in the room looked at that Guy.
The Guy slowly bent over one desk and pointing at the screen said
«It’s me…or there is missing a bit of padding in that label?»
What’s happened next? Well…
At the end the project succeeded, someone gave his life to save the servers from the room on fire.
But the Guy was found in the basement, dead. You have to find out the murderer, where the Guy was been murdered and with what.
The suspects are about 300 people…good luck.
Ok, maybe the scene is a bit exaggerated (…), but no matter if you are the Guy, the murderer or just a spectator, it is quite possible you are familiar with this.
There is a battle every time between “padding”‘s fan and “padding”‘s detractors.
Maybe it’s just me, but in these days a simple “front end website” is not a website anymore, it is a web application disguised in a front end website.
There is a lot of complexity in the data, different sources, third parties involved, so before to have a simple render of the page a lot of things should happen to make it possible.
So more or less the effort can be summarized in:
Depending on the Company/Team there is every time a big discussion if UI/UX should be considered part of the point 1 or the point 2.
But no matter how you consider the UI/UX, the problem in any case is:
No one can accept as a value the fact that the project/product/software is working (whatever it means), it is obvious that should work.
So your customer will look to the green bar to determinate if you did a good work or not.
Sadly it is quite possible that he will notice that padding.
Depending on the project/team you can plan to get not too much closer to the delivery date to start to implement the green part, so mocking data and organizing the work you can have something like this:
But even if you are brilliant and your team is great, while you are working following the plan and trying to keep everything in track, someone is working in order to change the plan: the change requests.
It is inevitable, you can be good and to be able to postpone a few/lot of things to a next release, but you can’t dodge all the bullets.
So this is what happens.
So what can you do? (suicide is not an option).
First of all you have to rearrange the release plan, because you can’t go live without being sure that the whole system will work as expected, so you have to push behind the deadline more “make the dreams come true” things and bring back “make it possible” things.
Now the system is safe, but the Customer won’t be happy, so you have to find a solution to get as much as possible “make the dreams come true” things before the deadline.
The most common solutions are:
1. Add more resources to the team
2. work overtime
The problems with those solutions are:
1. You are increasing the costs of the project. Of course it is better than to lose a Customer, but at the end you will have to give a lot of explanations to your manager, and it won’t be a great time.
2. You generate chaos in the team and…trust me, if I’m working till midnight and you ask me about the padding we go straight to the Cluedo situation. At least in jail I can rest.
When you are in a stress condition you think mostly how to survive, how to bring the ship in the harbor. You don’t care of the dust on the rudder or if there is a stain on your uniform.
So you will lose the padding.
But if you work from the beginning on the definition of your features you can reduce the scope without to renounce (sometime) to the whole feature.
You can reduce the overtime and easily manage the change requests.
In the last project I worked, me and the Project Manager couldn’t run a Scrum team, but we worked hard on the features and their scope, It took more or less one hour per day, but it was worth, totally.
From the point of view of the technical part I worked in TDD, all the code implemented respected pretty well the SOLID principle and to solve the change requests (sometime very heavy) hadn’t been impossible, even at the very last moment.
Reducing a bit the scope of every feature we were been able to apply all the change requests and deliver all the features expected.
One day before the launch a not-stressed-out developer came to me playing with the application on a mobile phone and said
«You know what? I’d like to add a few of padding here, it should look better. What do you think?»
In a good mood and with the right attitude everyone would care about the padding (without to be murdered).