In Chronological Order
A few years back, Mrs. C. bought me a reprinted collection of works by military theorists. It was originally published in the early 20th century (between WW1 and WW2). Lately I've been working my way through them.
Vegetius
This guy was a historian in the later period of the Roman Empire. He took it upon himself to review earlier Greek and Roman military theories and practices, and compile a summary of the high points. The stated purpose of the work was to advise the current Roman emperor of the best way to (re)organize his army, which like the rest of Rome had become decadent and weak.
The result is a surprisingly simple, straightforward book. It covers such topics as recruiting standards, equipment and training, order of battle, and establishment of camps. It also describes the chain of command and the duties of the officers of various ranks. And of course it reviews the Roman system of battle.
One of the most interesting arguments Vegetius makes is that the Roman armies of old were victorious in part because of their small size. Larger armies become too difficult to manage; better to field a smaller army, well trained and confident in the strength of its arms, under the direct command of a single general. He cites several historical examples of smaller, more agile Roman armies handily defeating much larger, unwieldy enemies.
Supposedly Vegetius was very highly regarded by strategists and generals during the Middle Ages. This makes sense, since the arms of that time would not have been much different from the arms of the Roman Empire.
De Saxe
A German officer who spent most of his career in French service, De Saxe formed his opinions of warfare during the early days of gunpowder, and it shows in his writing.
De Saxe proposed a reform of the armies of the day, into smaller units along classical Roman lines. He is credited by some military historians as being the father of the modern division-based army organization.
Gunpowder weapons being much less reliable and effective then than they later became, De Saxe argued against the practice of having the infantry fire while they advanced. He saw this as a waste of time that interrupted their charge, robbed them of their forward momentum, and left them vulnerable to a more aggressive opponent. He preferred the infantry to charge directly into hand-to-hand combat, exploiting the weakness of an enemy that had not taken his advice.
He had several other innovative recommendations, including a lightweight field gun that could move and fire in support of infantry action, rather than the larger artillery pieces, which comprised a separate arm of their own.
My favorite part of De Saxe's work is his note at the end, where he explains that he had written the entire thing during a seven day period while suffering from a fever, for his own amusement.
De Saxe was reportedly very popular with the strategists and commanders who came after him, throughout the Napoleonic period.
Frederick the Great
De Saxe died before gunpowder weapons technology had improved very much, and before anybody had gotten around to trying the reforms he suggested.
Frederick II, King of Prussia, deserves a lot of credit for putting De Saxe's ideas into practice, and also for coming up with many excellent ideas of his own.
As a young man, Frederick wanted nothing more than to be an artist. He even ran away to England to get away from his father, who had a more martial career in mind for him. But when his father died, and Frederick took the throne, he transformed into one of the greatest warlords in the history of the western world.
At that time, Prussia was a small nation with large, belligerent neighbors eager to add this tasty morsel to their domains. They would even form alliances with each other, for the purpose of conquering Prussia and dividing the spoils amongst themselves.
Frederick dealt with this problem by forming a well-trained, highly mobile army. He was renowned for the rapidity of his marches, and his ability to deploy his forces with surprising speed and deftness. Wherever the threat loomed largest on his borders, his army seemed able to spring to meet it and drive it back.
Frederick's Instructions to his generals include detailed plans for invading the regions neighboring Prussia. They take into careful account the differing geography and populations of each region. The Instructions also analyze the specific nature and personality of Prussian soldiers, that set them apart from the soldiers of other nations, and suited them to certain kinds of warfare more than others.
The Instructions were top secret, printed only in a limited edition. Each Prussian general was instructed, upon receipt of his copy, to never take it with him into the field. When finally one such general was captured with the book on his person, it was immediately translated into every European language, and widely distributed. Napoleon held Frederick's ideas in high esteem. Von Clausewitz points to Frederick the Great repeatedly, as an example of excellence in the "art of war".
Napoleon Bonaparte
Widely considered to be one of the greatest generals of all time, Napoleon had a lot of opinions about warfare, but never bothered to write them all down in one place. Several collections of his maxims, proverbs, and recommendations have been made over the years. The one I read was compiled in 1794(?), and attempts to present the ones that are universal while omitting all those relating to specific details that will change from time to time and place to place.
One of the most notable concepts Napoleon introduced was attacking from the march. Other armies, from the Romans onward, had an order of battle that was different from their order of march. It was a time-consuming and complicated process to transition an army from its traveling configuration to its fighting configuration.
Napoleon devised a way to launch an assault against an enemy from the marching configuration. Thus he could move his army into contact with the enemy, and just keep up that motion right into them while they were still in the process of transitioning. Even if they were already in position, Napoleon's troops could still save time and maintain their momentum by using this tactic.
To be continued...
Friday, August 28, 2009
Sunday, August 16, 2009
In Dreams
Or, Taking Care of Business
Last night was a good night, dream-wise.
Of the three dreams, I smoked in two of them. Not that smoking is good, but it's the first time I've dreamt about smoking. I guess the smoking dream is supposed to be common among ex-smokers, but I've never had one before. So it's kind of a milestone.
Yet another reason the 80s were awsome
I don't know why now, after almost five years. Maybe it's because I've been watching a lot of Miami Vice lately. Did you know that in 1984, the central figure of a network TV series could smoke on-screen?
Anyway
Anyway, in one of my dreams I was tagging along with a bunch of musicians. We were hitting all the downtown bars, looking for venues to play in. In which to play. One bar we went into, turns out I'd been there before, and run up a huge tab that I'd never paid. Not a problem: I settled up on the spot, and shared beers and ciarrettes with the owner, bartender, and musicians. So that was pretty cool.
In another dream, some guy wanted to hire me to do some kind of job for him, but instead I hopped on a train with a dreadbagged stoner hippie british dude and his girlfriend. Assorted dream shenanigans ensued. Highlights included more smoking, and criticizing a commercial landlord for working harder to decorate an office-building lobby than to find tenants for the building.
Shenanigans accomplished, we returned to see the man about the job. The interview was brief:
THE MAN: Tell me about your technique.
ME: Well, mainly I burrow underground, and when the mark leasts expect it, I burst up from beneath his feet and Pow! I take him out.
THE MAN: Excellent! Let me tell you about the mark.
ME: Actually, I have another technique where I tell the mark that the burrowing thing is my main technique, and then Pow! I take him out. You're the mark. Pow!
So that was pretty awsome, too.
In Conclusion
In conclusion, a good night for dreams. Had my first smoking dream(s), settled an outstanding debt, and very cleverly ninja'd the crap out of some dude who totally didn't see it coming.
Last night was a good night, dream-wise.
Of the three dreams, I smoked in two of them. Not that smoking is good, but it's the first time I've dreamt about smoking. I guess the smoking dream is supposed to be common among ex-smokers, but I've never had one before. So it's kind of a milestone.
Yet another reason the 80s were awsome
I don't know why now, after almost five years. Maybe it's because I've been watching a lot of Miami Vice lately. Did you know that in 1984, the central figure of a network TV series could smoke on-screen?
Anyway
Anyway, in one of my dreams I was tagging along with a bunch of musicians. We were hitting all the downtown bars, looking for venues to play in. In which to play. One bar we went into, turns out I'd been there before, and run up a huge tab that I'd never paid. Not a problem: I settled up on the spot, and shared beers and ciarrettes with the owner, bartender, and musicians. So that was pretty cool.
In another dream, some guy wanted to hire me to do some kind of job for him, but instead I hopped on a train with a dreadbagged stoner hippie british dude and his girlfriend. Assorted dream shenanigans ensued. Highlights included more smoking, and criticizing a commercial landlord for working harder to decorate an office-building lobby than to find tenants for the building.
Shenanigans accomplished, we returned to see the man about the job. The interview was brief:
THE MAN: Tell me about your technique.
ME: Well, mainly I burrow underground, and when the mark leasts expect it, I burst up from beneath his feet and Pow! I take him out.
THE MAN: Excellent! Let me tell you about the mark.
ME: Actually, I have another technique where I tell the mark that the burrowing thing is my main technique, and then Pow! I take him out. You're the mark. Pow!
So that was pretty awsome, too.
In Conclusion
In conclusion, a good night for dreams. Had my first smoking dream(s), settled an outstanding debt, and very cleverly ninja'd the crap out of some dude who totally didn't see it coming.
Thursday, August 13, 2009
Impressions
Today I'm adapting a script some other guy wrote, so that we can use it for our own purposes.
I always find it interesting to read other people's computer code. Scripting is a relatively new skillset for me, and there's always a lot I can learn from their approaches to problems.
I was going to say that his script looks pretty tight, overall, but after looking at it some more I've decided that it isn't, really. In fact, in a lot of ways it's really loose. More on that in moment.
He does use comments more liberally than I do, and they really do help me follow along with his train of thought.
On the other hand, he has an annoying tendency to name his variables things like "variable1", and "variable2". Or "value1" and "value2". Or even "variable_first" and "variable_second". This makes it very hard to follow along with his train of thought. Me, I believe that as much as possible, variable names should give some clear indication of what that variable is for. That way, whenever you see it, you know what it's up to.
On the third hand, he used a "case" loop, which I wasn't familiar with before today. It threw me at first. I was going to reach for my reference books, but decided to finish giving the script a once-over before doing any research. Further along, I realized that it was basically just an "if" loop, with the added advantage of being much easier to read. I'm quite comfortable with "if" loops, but I plan to start using "case" loops wherever possible. Anything that makes it easier for me to read and understand my own code is a bonus!
One of the most interesting things is that he has a lot of useless code, mostly commented out, so that it doesn't actually run. Code written with certain assumptions in mind, that later turned out to be untrue in certain environments. Code that has been replaced by temporary workarounds to some vexing problem the original code couldn't handle. A large, complex function--the bulk of his script, in fact--is never called because it has a show-stopping bug in it somewhere.
Me? That would creep me out, having all that dead code in there. One of my friends--an actual professional software developer--tells me that whenever he's adapting someone else's code, he always removes dead code, so that he's left with only the tight, live script that actually does the job.
I always find it interesting to read other people's computer code. Scripting is a relatively new skillset for me, and there's always a lot I can learn from their approaches to problems.
I was going to say that his script looks pretty tight, overall, but after looking at it some more I've decided that it isn't, really. In fact, in a lot of ways it's really loose. More on that in moment.
He does use comments more liberally than I do, and they really do help me follow along with his train of thought.
On the other hand, he has an annoying tendency to name his variables things like "variable1", and "variable2". Or "value1" and "value2". Or even "variable_first" and "variable_second". This makes it very hard to follow along with his train of thought. Me, I believe that as much as possible, variable names should give some clear indication of what that variable is for. That way, whenever you see it, you know what it's up to.
On the third hand, he used a "case" loop, which I wasn't familiar with before today. It threw me at first. I was going to reach for my reference books, but decided to finish giving the script a once-over before doing any research. Further along, I realized that it was basically just an "if" loop, with the added advantage of being much easier to read. I'm quite comfortable with "if" loops, but I plan to start using "case" loops wherever possible. Anything that makes it easier for me to read and understand my own code is a bonus!
One of the most interesting things is that he has a lot of useless code, mostly commented out, so that it doesn't actually run. Code written with certain assumptions in mind, that later turned out to be untrue in certain environments. Code that has been replaced by temporary workarounds to some vexing problem the original code couldn't handle. A large, complex function--the bulk of his script, in fact--is never called because it has a show-stopping bug in it somewhere.
Me? That would creep me out, having all that dead code in there. One of my friends--an actual professional software developer--tells me that whenever he's adapting someone else's code, he always removes dead code, so that he's left with only the tight, live script that actually does the job.
Monday, August 10, 2009
Meet the New Boss
Or, Re-ARGH-inization
Hasturcom just reorganized my... department? Section? I'm not sure what it's called, exactly. It's larger than a team, and smaller than a department, really. Assuming there are even formal sizes that go along with those words.
Anyway, whatever it is, Hasturcom just reorganized it. As far as I can tell, the new org doesn't really improve very much on the old org. They inserted another manager between my boss and his boss. His office unifies several teams that support various aspects of what I like to call Hasturcom's "enterprise e-commerce" operations, but what Hasturcom likes to call "business compute services" (yes, "compute").
They also created another manager at my boss's level, and transferred the database adminstrators on my team to this new manager.
Neither of these org changes make much sense to me. Enterprise e-commerce is, in my experience, very different from what I think of as "IT infrastructure".
IT Infrastructure vs. Enterprise E-Commerce
IT Infrastructure is internal, providing computing resources to the company itself and its employees. Enterprise E-commerce is external, doing business with paying customers. This defining characteristic--"doing business with paying customers"--places very heavy demands on Enterprise E-commerce. Demands that in most cases IT Infrastructure never has to satisfy.
As a result, there is a very different mentality on each side of the divide. IT Infrastructure is typically a nine-to-five, Monday through Friday kind of world. There's not a lot of investment in redundancy. Projects typically have longer timelines, and deadlines can usually be extended without too much complaint. Service outages on the order of a few hours or even a few days are tolerable. Formal "service level agreements", spelling out specific performance metrics and penalties for failure to meet them, are almost never drafted. If the email server dies over the weekend, it might be okay to wait until the tech gets in on Monday to fix it.
Enterprise E-Commerce, on the other hand, is much more. . . intense. Instead of 9-5, M-F, the schedule is 24/7/365. Your customers are online all day, every day, and your robots better be online, too. It's understood that for every server you have doing business, you have a second server running alongside it, just in case the first one breaks. Typically you have a third and fourth as well. You have staff on-site, and on-call, every hour of every day. Any interruption in service is unacceptable, and every incident must be remediated immediately. Projects typically have shorter timelines, and deadlines are very rarely changeable. Services "go live" on schedule, and they work right on Day 1 (and if they don't, the techs stay awake until the problems are solved).
Because of the "business-critical" nature of Enterprise E-Commerce, and because of the different paradigm which that nature requires, I feel very strongly that a company's EEC operations should be entirely segregated from its IT Infrastructure operations. EEC IT teams should be focused on the unique demands of the EEC world. They should be crafting policies and procedures specifically for EEC. Everything from hardware procurement, to system design and implementation, to managing the day-to-day operations should be handled by EEC-oriented teams.
The Hasturcom Way
But that's not how Hasturcom does it. Hasturcom only recently got into the EEC arena. Their "core business" isn't about selling goods and services to customers over the Internet. But the opportunity is there, and there's (potentially) a lot of money to be made by expanding into the EEC market. So Hasturcom recently started setting up computers and networks for this purpose.
At first it was kind of an ad-hoc thing. IT Infrastructure was already providing servers and networks for internal operations--how different could it be to provide the same things for external operations? And for a while, it really wasn't that different, mainly because IT Infrastructure didn't give much thought to how different it really should be.
Once Hasturcom did realize that EEC was very different from IT Infrastructure, they started trying to re-organize their IT department to address these differences. The resulting organization, which had been in effect for about six months when I came on board, was an abomination.
They had split the EEC IT support right down the middle. Resource procurement, system design and implementation, and even production deployments, are all handled by IT Infrastructure teams. Day-to-day maintenance and support is handled by what, in any sane world, would be EEC teams.
However, Hasturcom is not a sane world. There is no real EEC team. In fact, my department is a random assortment of IT teams. Some support Hasturcom's internal operations. Others--mine, for example--support Hasturcom's external operations.
In fact my team is the one which, having been totally out of the loop during the design, implementation, testing, and deployment phases of any new EEC service, must take over responsibility on Day 1 for that service, when it goes live and customers start using it.
Naturally, I've been thinking a reorg is in order since I first got here. If it were up to me, I'd remove IT Infrastructure from the picture entirely. I'd put my team in direct contact with the Hasturcom units that are developing these EEC services, so that we could work with them through all phases of development, and support systems we were intimately familiar with. As things are right now, all that intimate familiarity stays with IT Infrastructure, and doesn't cross the divide when they turn the system over to us.
Coming Full Circle
But that's not what Hasturcom has done with this reorg. Apparently, having realized that something is horribly wrong with the current reorg, they've created another layer of management, and sort of half-heartedly grouped together several disparate teams that are currently supporting EEC operations.
I guess this is a good start? I mean, sure, it's nice to see that Hasturcom is beginning to figure this out, but it doesn't really do anything to address the systemic horror of the current organization.
I figure, any time a company tries to solve an organization problem by adding another layer of middle management, something has gone horribly wrong.
Hasturcom just reorganized my... department? Section? I'm not sure what it's called, exactly. It's larger than a team, and smaller than a department, really. Assuming there are even formal sizes that go along with those words.
Anyway, whatever it is, Hasturcom just reorganized it. As far as I can tell, the new org doesn't really improve very much on the old org. They inserted another manager between my boss and his boss. His office unifies several teams that support various aspects of what I like to call Hasturcom's "enterprise e-commerce" operations, but what Hasturcom likes to call "business compute services" (yes, "compute").
They also created another manager at my boss's level, and transferred the database adminstrators on my team to this new manager.
Neither of these org changes make much sense to me. Enterprise e-commerce is, in my experience, very different from what I think of as "IT infrastructure".
IT Infrastructure vs. Enterprise E-Commerce
IT Infrastructure is internal, providing computing resources to the company itself and its employees. Enterprise E-commerce is external, doing business with paying customers. This defining characteristic--"doing business with paying customers"--places very heavy demands on Enterprise E-commerce. Demands that in most cases IT Infrastructure never has to satisfy.
As a result, there is a very different mentality on each side of the divide. IT Infrastructure is typically a nine-to-five, Monday through Friday kind of world. There's not a lot of investment in redundancy. Projects typically have longer timelines, and deadlines can usually be extended without too much complaint. Service outages on the order of a few hours or even a few days are tolerable. Formal "service level agreements", spelling out specific performance metrics and penalties for failure to meet them, are almost never drafted. If the email server dies over the weekend, it might be okay to wait until the tech gets in on Monday to fix it.
Enterprise E-Commerce, on the other hand, is much more. . . intense. Instead of 9-5, M-F, the schedule is 24/7/365. Your customers are online all day, every day, and your robots better be online, too. It's understood that for every server you have doing business, you have a second server running alongside it, just in case the first one breaks. Typically you have a third and fourth as well. You have staff on-site, and on-call, every hour of every day. Any interruption in service is unacceptable, and every incident must be remediated immediately. Projects typically have shorter timelines, and deadlines are very rarely changeable. Services "go live" on schedule, and they work right on Day 1 (and if they don't, the techs stay awake until the problems are solved).
Because of the "business-critical" nature of Enterprise E-Commerce, and because of the different paradigm which that nature requires, I feel very strongly that a company's EEC operations should be entirely segregated from its IT Infrastructure operations. EEC IT teams should be focused on the unique demands of the EEC world. They should be crafting policies and procedures specifically for EEC. Everything from hardware procurement, to system design and implementation, to managing the day-to-day operations should be handled by EEC-oriented teams.
The Hasturcom Way
But that's not how Hasturcom does it. Hasturcom only recently got into the EEC arena. Their "core business" isn't about selling goods and services to customers over the Internet. But the opportunity is there, and there's (potentially) a lot of money to be made by expanding into the EEC market. So Hasturcom recently started setting up computers and networks for this purpose.
At first it was kind of an ad-hoc thing. IT Infrastructure was already providing servers and networks for internal operations--how different could it be to provide the same things for external operations? And for a while, it really wasn't that different, mainly because IT Infrastructure didn't give much thought to how different it really should be.
Once Hasturcom did realize that EEC was very different from IT Infrastructure, they started trying to re-organize their IT department to address these differences. The resulting organization, which had been in effect for about six months when I came on board, was an abomination.
They had split the EEC IT support right down the middle. Resource procurement, system design and implementation, and even production deployments, are all handled by IT Infrastructure teams. Day-to-day maintenance and support is handled by what, in any sane world, would be EEC teams.
However, Hasturcom is not a sane world. There is no real EEC team. In fact, my department is a random assortment of IT teams. Some support Hasturcom's internal operations. Others--mine, for example--support Hasturcom's external operations.
In fact my team is the one which, having been totally out of the loop during the design, implementation, testing, and deployment phases of any new EEC service, must take over responsibility on Day 1 for that service, when it goes live and customers start using it.
Naturally, I've been thinking a reorg is in order since I first got here. If it were up to me, I'd remove IT Infrastructure from the picture entirely. I'd put my team in direct contact with the Hasturcom units that are developing these EEC services, so that we could work with them through all phases of development, and support systems we were intimately familiar with. As things are right now, all that intimate familiarity stays with IT Infrastructure, and doesn't cross the divide when they turn the system over to us.
Coming Full Circle
But that's not what Hasturcom has done with this reorg. Apparently, having realized that something is horribly wrong with the current reorg, they've created another layer of management, and sort of half-heartedly grouped together several disparate teams that are currently supporting EEC operations.
I guess this is a good start? I mean, sure, it's nice to see that Hasturcom is beginning to figure this out, but it doesn't really do anything to address the systemic horror of the current organization.
I figure, any time a company tries to solve an organization problem by adding another layer of middle management, something has gone horribly wrong.
Subscribe to:
Posts (Atom)
Posts
