Why design matters
So today I was handed a bug report from a client on our newest software release. It was a strange one involving permissions when running batch jobs. It was not duplicatable in-house and we had the client demo it for us. They were able to do so, and after reviewing their system I found that one of our standing server programs was running in test mode out of the test install, but as the wrong user (owner). Digging down through the code, reviewing interactions with the client, after 4 hours I understood how this happened. The client had installed the software for testing using the standard procedure but had hit an issue with running a sub-system of the software. They contacted support and support restarted several servers on the test install. This was done correctly by them. However, when they restarted the servers using the tool they were supposed to, the servers were restarted with the wrong owner. This occurred because one of my co-workers loves to duplicate or triplicate things either directly in code or indirectly in parallel processes. This is one of those cases.
Turns out there are two paths to run these server programs this developer implemented, one is used when bringing the software up from cold and one when restarting them individually. A project was implemented in the current release to change the ownership these servers run under, and the same developer who implemented the system originally including the parallel paths was given the job. Turns out, he only changed one of the paths to run with the new user.
Design matters. We have had a long standing (20+ year) design for the start and stop of these types of servers that ensures there is only one code path required that supports starting and stopping them for both an entire system and individual installs of the code. But no, he knew better how to do it better than we did (he said so back in the day) and now we have a sub-system that we can install but cannot restart. Tomorrow I fully expect him to go to his boss because he is over loaded with bugs and ask to have me do it and it will probably end up being my responsibility to fix it.
Why agile isn't for everyone
So, I’m having another agile day. I’m reviewing code that has been checked into our baseline and 5 out of 5 comments made are design comments. From simple things like making variable names descriptive to questions on the interaction of this code with older code. All of this is because the person who coded this isn’t that good and needs detailed design guidance on a daily basis. Instead of doing this up front, we the people reviewing the code are doing it on the back end. And for everything we miss that affects functionality, the clients will find when they run the code.
The other agile thing today is I’m being asked about the design for a different change. Turns out this junior person has been turned loose on a project. His idea is to allocate about 250K bytes of space for each process running, and our large clients run 4 or 5 thousand of these processes. This is in an area that handles exception processing, and this memory is intended to make the exception processing go faster. The thing is, if this exception processing gets tripped once a week (across 700 clients and 50,000 users) then it is a bad week. And when it does run, it is a major work stoppage for that user, so there is no need for this to be optimized in this way. Does he understand this? Not yet and I’m on my third go around on this with him on this improvement.
Both of these come down to if the senior people set the detailed design up front, then we can educate these individuals as to why we design and build in this system in a certain way, and our time is properly accounted for toward those projects. Instead, these are interruptions to my current work, I'm just going to provide the minimal guidance necessary without necessarily providing a detailed why, and even then my time is lost from the project I'm supposed to be working on and going towards these other projects. Even if I did provide guidance up front, for these two individuals they are really not intelligent enough (or maybe willing in the case of the first person) to absorb the lesson. I feel for them in that mostly get negative feedback on their work and proposed changes, instead of design guidance they need. Worst of all, management will not allow us senior people to account for these interruptions against the project they are originating in, making us all look bad or resulting in us working unpaid O/T to make up for it.
