Warren
Posts: 5
Nickname: curmudgeon
Registered: Apr, 2004
|
|
Management vs. Software Development
|
Posted: Apr 5, 2004 5:10 AM
|
|
Like so many of the articles in this series, Entropy Reduction is about the things that need to be done Organizationally that the manager (or the PHB) may not not know about. Certainly there was nothing about this in school when he or she got that MBA.
All disciplines have specific things that need to be done that are simply unknown to newly-minted general managers (or good old boys on the board of directors), of course. Ditch diggers need to actually sharpen their shovels with grinders or rasps. Physicians sometimes need extra time to consult or just listen to the patient. And so on.
Software development has weird organizational needs that should be in the domain of advanced technical leadership, but that leadership is often lacking, and what we are left with is managers who are mere customers, who only understand what they can see today on the screen or printout.
There is are real arguments, you see, for not "Fooling around" with working software by "Refactoring" it or "Reducing Entropy". You don't know what bugs you have introduced unless you have tested it thoroughly and and probably beta-tested it with live customers. And live customers will refuse to beta-test unless there are new features. So you end up debugging your newly-introduced "Fixup" bugs along with the new features of the next release.
And system testing the new software might entail a small army of testers who have other things they ought to be doing. Some system tests involve setting up networks of computers and having masses of data pumped through the network. And any change at all to software build could conceivably change the tests, even though you are just "Refactoring". Because when you are refactoring, you will come across terribly illogical things in configuration files or in temporary files or in progam inputs and outputs that just cry out to be changed. Especially if you are "Reducing entropy" and not just formally refactoring. But the test team has set up special configuration files and inputs and outputs that no longer will be relevant after the "Harmless changes" you make.
So you had better be sure that the next release will really truly benefit from the "Fooling around" you are doing "Off budget" and between releases. Because you will be blamed for any bugs that show up.
And of course when the bug reports start flowing in, you will be pulled off of refactoring to fix bugs. So you do both and account for it as bug fixing!
Not that reducing entropy is wrong, and certainly refactoring is not wrong. But these things have costs that need to be considered and managed in the light of the overall budget and whatnot. And if your budget-level management simply cannot imagine what the hell Refactoring or Entropy Reduction is, because they are not now and never have been software developers, decisions will be made without rationality. Unless of course the software developers actually know how to communicate with human beings, which is, shall we say, not guaranteed.
One result of all this is that management complains that managing programmers is like herding cats. The Human Oriented Architecture has to include the suits, too. Now with lots of software development being done offshore in India, does Conways law change it's impact? And is managing underpaid Indians like herding cats? Will they refactor more or less?
Or will my whole thesis be blown out of the water because, in an era of a glut of software engineers, all the IT managers will also be experienced developers all over the world, and not just at Microsoft and IBM and parts of the Aerospace industry?
|
|
Previous Topic
