Muddling through the day, a little more relaxed now that I know that I will continue to have a paycheck.
Interesting meeting today. The head of process development came to our meeting today and asked us for our input on what we thought could be improved in the development process.
Now this is important, because the previous process head was only beholden to upper management, and upper management defined the process. Thus some brain-dead-clueless processes were made. Like deciding that it would be a good idea to make estimates on software before doing things like analysis and architecture.
We had a number of suggestions. Some very good ones. And they seemed to be taken to heart. If these things actually get accepted as part of the process, this may actually become a good company to work for.
Perhaps my breath should not be held.
I'm guessing that the senior management will not take kindly to suggestions that will add steps to the process. The biggest suggestion that I had was the addition of a requirements analyst/manager in between marketing specification and software requirements. Right now they don't have this step, and it's a doozy which will add a couple of physical bodies and a couple of months of time to the development process. Of course, that work needs to be done eventually, and as it is it gets spread out into the project causing changes and delays roughly three times what it would have been had it been done up front.
Another suggestion was a systems analyst/architect. Someone who understands control systems and physics and can deal with how the entire system interacts. Again, REALLY good idea.
There were some smaller suggestions as well. Mostly with how to fix the existing processes that are broken.
I felt good that we were even asked. These are not just off-the-cuff suggestions, these are things that have been plaguing us since the beginning, and for someone to recognize that we might actually know what we need is a Very Good Thing®.
Of course, it could be yet another empowerment blind. Spend some time getting suggestions, report the results to management, then nothing is done.
It wouldn't be the first time.
I do have some kernel of hope though. This new guy has done a lot to create good processes and fix bad processes that were in place along the way. So maybe-- just maybe-- this will actually come about. It won't affect what I do, because I will be gone before the next project; but it will feel good to know that I perhaps had an impact on making improvements.
Another fun bit: I'm overstepping my bounds in a big way on making some user-interface design decisions. I'm doing this because these decisions are needed, and they have not been considered previously to this point, and the operation needs to be defined before we can continue.
Some of the spirit is coming back.
This project is going to wallow a whole lot in the near future. The user interface stuff that we are doing now is turning out to be huge and complex and full of stuff-that-nobody-has-thought-of-yet. And in all actuality, our user interface portion is only about 20% of the UI for the system-- the other teams haven't even begun to consider it yet.
When they get there, it will be *ugly*.
This is a massive project. Not the largest project I've worked on, but it's still freaking huge. And I'm realizing that it takes a different sort of approach to deal with a project of this size and scope than it does for a small couple-man team project.
Some things remain constant:
You need to know what it is you are doing before you can do it.
You need to know what it is you are doing before you can estimate how much time it will take to do it.
You need to know what it is you are doing before you can figure out a way to test it to see if it works.
There. Are. No. Shortcuts.
Extreme programming/pair programming (XP) is not a shortcut. Nor is it a solution to all of your problems. It is a method of development that has advantages in certain types of systems-- control systems and mission-critical applications are not those types of systems.
Developers don't make mistakes on purpose. However, they may make some decisions on purpose that may come out as bugs. For example, there is a user-interface issue which I dislike. When a listbox is displayed that consists of a selection of items and one of those items is currently operational, I would like to see that selection defaulted in the listbox. This makes a whole lot of sense to me.
However, there is currently no method available to provide this operational selection to the owner of the listbox. And because it is not a "requirement" (i.e. it hasn't been identified by marketing as something that they specifically want), I can't add it to my list of things to do.
So when this system is finally running, somebody will notice that when you browse the list, the item that is currently selected in the list is NOT the current operational parameter. And it will get reported as a bug.
Then there will be meetings, because it's not really a bug, it's a new feature request, and that will take time to implement, and so on.
It's part of the development game.
I hate it.