Why Software Development is Hard
I was installing a POE IP camera in my garage. The garage has garage doors for vehicles (obviously!). My family wanted a camera in the garage because the existing cameras are all outside the house, none of them shows whether the garage doors are open or not. So, we have to open the garage entrance to the house door to find out whether any of the garage doors is open (such a Herculean chore, I know). What kind of IP cameras, and why automatic garage doors are such insecure beast, those are two other issues that are fascinating. I will deal with them in the future. Maybe.
So, since the garage does not have an ethernet port, an oversight of my part when the house was being built, I had to use POE to provide the network link and power to the camera. Yet another fascinating topic about technology that I sure have observations about.
In any case, the camera was installed. Before it was permanently secured to the wall, I put Velcro to attach the camera to the wall. Then I asked everybody in the family to check if that is fine. Yes, yes, yes, were all I heard. Okay, time to screw the camera in. After that was done, I asked again. All good, right? Nope. “Can’t see the side door”.
This is a wonderful analogy to software development, matching very well to my experience of decades of experience about the dynamics of software development.
Requirements are hard not because they were necessarily hard by nature. The reason why they are hard is because people don’t think in specific terms about requirements. “A camera to show whether the garage doors are open”. Specific enough? I know the house and the garage very well, having lived in the house for more than seven years by now. So, the architecture part, the decisions on what camera to use, how to connect the camera to the home network, how to isolate the camera from ever phoning home, etc., were done. Of course I disable the camera’s ability to call some weird computer somewhere. Ha! Yet another topic to talk about.
The design is the simple part: putting the camera where it can see all the garage doors. Adjusting the camera to show the doors in the best light was not that hard but tedious.
Attaching the camera with Velcro was the beta testing phase. The beta testers, my family, all thought it was good. It passed with flying colour.
Then, of course, the deployment. The camera was screwed in. Permanently attached to the wall now. In production! Hey, family, check the camera out.
“Can’t see the side door”.
But but but… it was not in the requirements.
The “customers” did not buy that argument. It was obvious, no? If a camera is placed in the garage, why not show all the doors?
“Can’t see the entrance door to the house either”. Well, no, that should be done by a camera in the house, not in the garage. “Fine”.
So, yeah, I had to go back to the design phase, re-adjusted the camera to show all the doors in the garage, except the house entrance. But since the camera is already screwed in, I could not make it show the doors all squarely nice and level. I guess I can re-locate the camera (“never rewrite”, right?). But that is quite a bit of work. Not saying it is not worth the effort, but it is not worth the effort.
So, the current state of the camera does show all the doors, so the modifications (bug fixes) did do the work, but the “customers” are sort of okay with it. Just okay. Damn faint praises all around.
If something this simple can have this kind of complications with requirements and dynamics, given that software development is thousands of times more complex, of course we have a problem having perfect software development.
And this episode is very nice for illustrating where the waterfall process can be a problem, and where the agile process have advantages and disadvantages. Since it could have happened in such a way that will make either or both processes to look bad, there is really no perfect development process that is good for all circumstances, let alone in all possible scenarios that can arise before, during, and after development.
