Well there are three interesting set of problems to address:
- Leadership v. Management
- The roll of Boolean in discourse
- OpsEng v. EngEng
What I found really freaky as we were working things through on other stuff, was this old distinction
You Lead People,Which has been a warMonger maxim since I was a wee tyke. Yes, there are all kinds of ambiguities in the civilian sector about where 'leadership roles reside' and how much of management is managing and how much of it is leadership. So of course we started with the old skool
and you manage things.
What is the difference between a 3rd class petty officer and an Ensign?complete with the obligatory rim shot sound. But we also see this in many software team leads. They are stuck in the hard spot where they are sorta management, and if they are any good, they focus first on their leadership skills. Since their single most important asset are the people that make up the crew.
The 3rd class has had to demonstrate leadership.
What clearly sets good leaders apart is their interesting range of 'people skills'. We can get diverted into the Testosterone issues, and I always advocate Heartbreak Ridge - with clint eastwood here. But let us defer that misadventure. Since, until we start hiring coders from outside of the MonkeyClass, well, we will be dealing with testosterone issues. So let us take it as a given that if there is testosterone in the system, there will be those who fail to manage the issues well.
By focusing the leadership part in the people skill space - we are looking at the whole range of problems that are often overlooked when the dialog gets side tracked into 'warStuff' and 'testosteroneMachismo'. When what we can see is that there are ugly pointy haired managers who really will never be good leaders, because they actually lack the required suite of people skills. ( in this space I of course advocate Cross of Iron which many confusingly perceive as Pekinpah's masterful war movie. When anyone who looks deeply into it understands is the tale of a software development team on the death march, with, well, that interesting management like entity, the aristocratic Prussian officer, Captain (Hauptmann) Stransky, who doesn't really care who gets flamed, just so long as he gets hi CrossOfIron.
Ok, I am willing to confess that this may be influenced by my time with Enron. But I am sure that there are others who have been on the Eastern Front of Software/IT.
So what we may need to acquire are not merely 'project managers' who are able to manage projects, but actual real live leadership that understands the problems of dealing with people, and having people in the loop. I do not believe in 'the majik bullet' - but I am also amused that those who have taken the time to review the special warfare case studies, also notice that there are some interesting ideas that start to become common across the main line of advance. What if we engage the coders in the loop, engage them in actively owning their part of the process. Then moving along to the part where there is the need to stay hot, stay sharp, stay on the top of their game. That might be a great way to revitalize the software development process.
Now we move from managing codeGinningUnits, to engaging people in the software development life cycle.
It could happen.
The role of boolean in discourse offers us the problem that various languages do not have our english language notion of boolean in the form of their language. I am speaking here from tales told to me by friends. What brought this into the dialog was one more case of confusing the 'yes' that denotes the 'I am in receipt of your verbalization' with 'I concur with your position' and that there is a clear and compelling need to have ways in which we do not depart into the 'lost in translation' problems. For me this is the land of much beloved IRONY - since when I was growing up, I was opposed to the 'elitist' approach of mandating a second language, such as latin, greek, or cheeseEatingSurrenderMonkey. Since that really did not appear to add value to the revolutionary cause!
But now the studies are coming out that show that learning an additional language is useful for a wide range of skills. Just as the value of being in a decent day care/pre-school system will help the kids grow up and be more well rounded. It would be nice to see america once again in the pursuit of excellence. But that way will of course mean having to deal with some of our quaint cultural myths.
IF we allow for excellence, then we will need to allow that some have 'better than' abilities. But that these do not allow them to be above the law. Merely that they have an aptitude for awesome that they really need to work on. That is the messy part of the whole spectrum world where everything is not in a simple singularity of being all alike. You know, that melting pot mythos. But doing this in a way that does not retreat into institutionalize inequalities.
That a person may ack the receipt of the message, and not the content, is a dialog issue. It is a part of the need for a cultural awareness that there may be more than just bland syncretism. Which may not be a bad thing! Especially if it frees us from having to carry The White Man's Burden - and that we who have a given set of language tokens are thus blessed with civilization that we must bring to the brightly painted savages. ( see also Linguistic relativism which offers an nice write up of the area around the Sapir-Whorf Hypothesis - which at times has been used to defend various forms of Cultural Imperialism. )
There is of course the horror of the joke
Heisenberg, Goedel and Chomsky walk into a bar. Heisenberg says "This is very odd and improbably, and I wonder if we might be in a joke, but I can't be certain." Goedel says "Well, if we were outside the joke we would know, but since we're inside the joke, there's no way of determining whether or not we're in a joke." And Chomsky says "Of course this is a joke, but you're telling it wrong!"because sometimes a quick google and a cut and paste beats the failures of street preaching liberals who wind up BEING the Chomsky in the moment.
[ citing the bar joke ]
The third fork was about the problems of OpsEng v. EngEng. Where we have the interesting sets of issues about how should software development be allowed, and what can we do to prevent it in our lifetime. Having found myself working with refactoring code that started out in OpsEng, where it is all to often written in haste, there is a duality I am still working on here. Do I defend my cultural roots in OpsEng over and against the cultural bigotry of EngEng, where at times they are all a bunch of hoity toity sniggle bottoms who have no idea what it is like to work hot and fast with the tools at hand, without the luxury of being pedantic about the problem.
Or, do I step back and look at a bigger picture. Why is it that Management always allows these sorts of problems to arise? Could it be that the EngEng does not have anyone in their crew with the people skills to be able to come over, offer some technical support, in a way that will be hearable to the OpsEng folks? What? A matter of leadership skills, where we are talking about parachuting some GreenBeenie into the bush with the brightly painted savages to offer an A-Team assist to the folks at the pointy end of the spear? ( granted, this would also mean that we KNOW that there is a B-Team backing them up, and... and... and... )
{ pedantics - Special Forces (United States Army) and the terms are ODA and ODB... but you know the MONKIES, give them technical terms and they move from Operational Detachments Alpha to A-Team.... }
At some other time we can get into the 'my software development buzzPhraseBing beats yours' - but at the pointy end of the stick, one of the reasons that Perl got so hot as the buzz of choice for sysAds and ops folks was that it solve a lot of problems and came with a lot of ways to solve them. So that one could get down and dirty and fixed fast. But that fixed means two other core issues:
a. something was brokenThe former is a problem that will happen. Some of that is a matter of better process, so that fewer things have built in bugs that blow up at nasty and awkward moments. The other part of the problem is that not only do we have a way to work around the current problem - we have also created a new set of bug tracking issues.
b. this tool may live longer than this event
Yes, one solution is to not allow sysAdds and OpsMunchKins to write scripts, apps, tools, code stuff.
The other of course is to work on how to provide them with better frameworks, applet-containers, yada-buzz-here. But also, more access to the collected cultural heritage and wisdome that is wandering around amongst the other CodeMonkies.
Or as too many know
We got us some best practices,And so yes, OpsEng coding is in a different context than the more sanguine software development models. But it is STILL about coding, and hence about how to code well the first time.
Caused we tried all the others first.
So who knows, the three topics revolve around the problem of working the correct people skills into the mix. But how are we going to get there.... That is what I guess we are all going to be working on.