Prussian Generals

(I gave a 10 minute presentation about the agile Prussian army at the last OpKoKo. It was well received, and I considered sharing the slides, but they don't say that much on their own. I converted it to a blog post with the gist of the presentation instead.)

What can agilistas learn from 19th century Prussian generals? Not much, it would seem. But bear with me, all will be revealed.

But let us start at the beginning. The year is 1800, and the Napoleonic wars are in full swing. Napoleon had a pleasant problem, with too many soldiers to command. Reform was necessary, and he came up with the concept of army corps (Corps d'Armée). A corps was a mini army with its own infantry, cavalry, and artillery, and a fairly independent commander. All in all about 20-30,000 men. The general staff was used to help control all corps in the army. A general staff in the modern sense was a product of the French revolution, and Napoleon benefited enormously from its invention.

French army size at Austerlitz and Wagram

As Napoleon demonstrated the superiority of his style of warfare, other nations started to copy his and France's ideas. Prussia was an early adopter of the French ideas, and it was Prussia who would carry the torch after the demise of Napoleon.

Carl von Clausewitz

Carl von Clausewitz served in the Prussian army, and later in the Russian army during the Napoleonic wars. Soon after the wars ended, in 1816, he started a work on the art of war. He never finished, instead dying from cholera in 1831. His widow published "Vom Kriege" ("On War") posthumously in 1832. Exactly how complete On War was has been hotly debated, but regardless it is considered to be the major treatise on the art and philosophy of war in the western world.

Some interesting points and concepts in On War are:

• Friction, things rarely go as planned when tiny problems accumulates. Roads are more difficult than envisioned, the weather is slowing movement, soldiers get drunk, and so on.
• Fog of war, commanders on all levels will have limited intelligence on which to act, and lack knowledge of the overall picture.
• War is the continuation of policy by other means. A phrase that has been misinterpreted as advocating war over politics, but what Clausewitz really means is that politicians must be the ones to decide if and when war is warranted, and what the goal of war is.

The first two points means that a commander must act and react swiftly on the information at hand. It is as necessary to adjust in the face of bad luck (or preparations), as it is to grasp opportunity when it presents itself.

The third point is important in that it means that war takes place in a context and, like it or not, politicians have a huge impact on how war is waged.

Helmuth von Moltke

Clausewitz found one of his most ardent supporters in Helmuth von Moltke. Moltke coined the phrase "No battle plan survives contact ?with the enemy", advocating adaptability at all levels.

Moltke became Chief of the Prussian General Staff in 1857, a position he held for the next 30 years. When his plans to defeat the Danes in the Second Schleswig War was bodged, he intervened and saved the day. Given this success, Moltke was influential enough to get his way in future wars. Prussia won major wars against Austria (1866), and France (1870-1871).

Though a great strategist, his key to success was meticulous preparations. (Moltke would probably consider that an important part of the strategy.)

• The Prussian war academy trained officers for staff service, and since the cadets were encouraged to socialize and befriend each other, a powerful social network was created within the Prussian army.
• Possible army movements was mapped out in detail. Thus commanders knew their logistical options instead of having to discover everything as they went.
  
• War games was used extensively to gain experience in maneuvering troops. (Moltke used blue figures for friendly troops and red for the enemy, colors that are still used today.)
• Commanders, on all levels, were encouraged to continuously assess the situation, and adjust their plans accordingly. To adjust was more important than to follow orders. One could in fact be reprimanded for following orders, if it meant that opportunities were missed.
  

The social network led to ad hoc collaboration on the battlefield. Intelligence and war game experience led to better, more informed decisions. Command culture led to exploiting enemy weaknesses and countering their strengths, dynamically, on the battle field.

During the second half of the 19th century, the Prussians were invincible.


Wait a Minute

Do you recognize :
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Here is the complete manifesto

How does the Prussian army hold up against these ideals?

1. While the Prussians instituted processes and used the best tools available, they clearly favored individual decisions and collaboration. The deliberate fostering of informal social networks, and emphasis on responsibility and empowerment of individual officers is dead on.
2. Software was pretty uncommon at the time, but if we broaden software to include process and its documentation, I think it's fair to say that Prussia loved comprehensive documentation, but "No battle plan survives contact with the enemy". If process was broken, it was fixed on the spot.
3. I haven't touched on it, but Moltke collaborate with the political side, with good relations with Bismarck and the king, to ensure that the customer, Prussia, get the most from its army.
4. Moltkes war plans all fail, but the wars are won. Commanders on all levels reacts to and handles setbacks but, perhaps more importantly, grasp opportunities when they arise.

So, in my book the late 19th century army is the poster child of agile.

Conclusions

The Prussian example shows that agile thoughts are not new, and we can learn from their experience. In particular:

• Agile works in large projects
• Requires not only freedom in how follow orders, but even the right to break orders if they are deemed to be wrong (e.g. outdated or too costly)
• Skill and experience is required to navigate the fog and deal with friction along the way
• Local responsibilty requires authority and autonomy
• Communication is vital, and informal communication channels are as important as formal ones

References

• Militär ledning, Marco Smedberg (Swedish)
  
• Om kriget, Carl von Clausewitz (Swedish translation)
  
• The lazy project manager, Peter Taylor
• agilemanifesto.org
• www.clausewitz.com
• The role of leadership in software development - Mary Poppendieck (8:00 - 10:40)
• Wikipedia

Prussian Generals - part 5, Conclusions

Conclusions:

The Prussian example shows that agile thoughts are not new, and we can learn from their experience. In particular:

• Agile works in large projects
• Requires not only freedom in how follow orders, but even the right to break orders if they are deemed to be wrong (e.g. outdated or too costly)
• Skill and experience is required to navigate the fog and deal with friction along the way
• Local responsibilty requires authority and autonomy
• Communication is vital, and informal communication channels are as important as formal ones

References:

• Militär ledning, Marco Smedberg (Swedish)
  
• Om kriget, Carl von Clausewitz (Swedish translation)
  
• The lazy project manager, Peter Taylor
• agilemanifesto.org
• www.clausewitz.com
• The role of leadership in software development - Mary Poppendieck (8:00 - 10:40)
• Wikipedia

A Dysfunctional Web Server Component

Have you ever wanted a tiny web server that you can just embed in your projects? Well, here is one anyway. It's not feature complete, in fact it treats all requests as GET, there is no error handling, and it only produces text/html pages (and by lying at that). It's usable but ... dysfunctional.

Looking at the code, you'll realize it's not fully functional ... dysfunctional.

To use the web server, include it in your code and register page handlers for the pages you need. Look at the UsingTheServer object to see how. It's pretty self-explanatory i hope. The pages map is populated with known pages, and when a page request is made, the web server tried to match the request against the pages map. If found, the partial function is executed.

You can use XML directly in Scala code, and this is where the server lies a bit. Instead of using HTML, we use XML that looks enough like HTML to fool the web browser. (OK, the browser won't be fooled, just tired from the lousy HTML quality nowadays...)

object WebServer {
var server: WebServerInstance = null

def main(args: Array[String]) {
  if (args.length == 1) {
    server = new WebServerInstance(args(0).toInt)
  } else {
    server = new WebServerInstance()
  }

  server.pages += ("/index.html" -> ((method: String, path: String, query:String) =>
  
    
    
        <p>Welcome to { path }. I see you are trying to {method}. The answer is {path + query.reverse}</p>
    
    ))
  server.pages += ("/" -> ((method: String, path: String, query:String) =>
    server.pages("/index.html").tupled(method, path, query)))
  server.start()
}

class WebServerInstance(val port: Int=8080) extends Thread {
  import java.net.{Socket, ServerSocket}
  import actors.Actor
  import java.io.BufferedInputStream
  import collection.mutable.HashMap

  val server = new ServerSocket(port, 100)
  val renderPoolSize = 5
 var renderers = List[PageRenderer]()
  for (i <- 1 to renderPoolSize) renderers = new PageRenderer :: renderers
  renderers.foreach(p => p.start())
  var pages = HashMap("default" -> ((method: String, path: String, query:String) =>
  
    
    
        <p>Welcome to { path }. I see you are trying to {method}. Your question is {query}</p>
    
    ))

  override def run() {
    var i = 0
    while (true) {
      try {
        val connection: Socket = server.accept
        renderers(i) ! (i, connection)
        i = (i+1)%renderPoolSize
      } catch {
        case ex: Exception => ex.printStackTrace()
      }
    }
  }

  class PageRenderer extends Actor {
    def act() {
      loop {
        react {
          case (id: Int, connection: Socket) =>
            try {
              val in = new BufferedInputStream(connection.getInputStream)
              var c: Int = 0
              var request = new StringBuilder()
              do {
                c = in.read()
                if (c != -1) request.append(c.toChar)
              } while ( in.available() > 0)
              println(request)
              val method = request.substring(0, request.indexOf(" "))
              val url = request.substring(method.length() + 1, request.indexOf(" ", method.length()+2))
              val path = if (url.contains("?")) url.substring(0, url.indexOf("?")) else url
              val query = if (url.contains("?")) url.substring(url.indexOf("?") + 1) else ""
              val out = connection.getOutputStream
              val html = if (pages.contains(path)) pages(path).tupled(method, path, query)
                else pages("default").tupled(method, path, query)
              val response = new StringBuilder("HTTP/1.0 200 OK\r\n" +
                "Server: labserver\r\n" +
                "Content-length: " + html.toString().length() + "\r\n" +
                "Content-type: text/html\r\n" +
                "\r\n" +
                html
                );
              val binaryResponse: Array[Byte] = response.toArray.map(c => c.toByte)
              out.write(binaryResponse)
              in.close()
              out.close()
              connection.close()
            } catch {
              case ex: Exception => ex.printStackTrace()
            }
        }
      }
    }
  }
}
}

object UsingTheServer {

def main(args: Array[String]) {
  WebServer.main(Array("8080"))
  MyStuff.getClass
}

object MyStuff {
  var events = List[String]()
  WebServer.server.pages += ("/addStuff" -> ((method: String, path: String, query:String) =>
  
    
    
        <form action="/doAddStuff" method="GET">
          <p>Submit your title.</p>
          <input name="title" type="text"/>
          <input type="submit"/>
        </form>
    
    ))
  WebServer.server.pages += ("/doAddStuff" -> ((method: String, path: String, query:String) => {
    events = events ++ (query :: Nil)
    events.foreach(println)
    WebServer.server.pages("/addStuff").tupled(method, path, query)
  }))
}
}

Prussian Generals - part 4, Take a Step Back

Do you recognize :
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Here's the complete text

How does the Prussian army hold up against these ideals?

1. While the Prussians instituted processes and used the best tools available, they clearly favored individual decisions and collaboration. The deliberate fostering of informal social networks, and emphasis on responsibility and empowerment of individual officers is dead on.
2. Software was pretty uncommon at the time, but if we broaden software to include process and its documentation, I think it's fair to say that Prussia loved comprehensive documentation, but "No battle plan survives contact 
with the enemy". If process was broken, fix it on the spot.
3. I haven't touched on it, but Moltke collaborated with the political side, with good relations with Bismarck and the king, to ensure that the customer, Prussia, got the most from the army.
4. Moltkes war plans all fail, but the wars are won. Commanders on all levels reacts to and handles setbacks but, perhaps more importantly, grasp opportunities when they arise.

So, in my book the late 19th century army is the poster child of agile.

Prussian Generals - part 3, Moltke

Clausewitz found one of his most ardent supporters in Helmuth von Moltke. Moltke coined the phrase "No battle plan survives contact 
with the enemy", advocating adaptability at all levels.

Moltke became Chief of the Prussian General Staff in 1857, a position he held for the next 30 years. When his plans to defeat the Danes in the Second Schleswig War was bodged, he intervened and saved the day. Given this success, Moltke was influential enough to get his way in future wars. Prussia won major wars against Austria (1866), and France (1870-1871).

Though a great strategist, his key to success was meticulous preparations. (Moltke would probably consider that an important part of the strategy.)

• The Prussian war academy trained officers for staff service, and since the cadets were encouraged to socialize and befriend each other, a powerful social network was created within the Prussian army.
• Possible army movements was mapped out in detail. Thus commanders knew their logistical options instead of having to discover everything as they went.
  
• War games was used extensively to gain experience in maneuvering troops. (Moltke used blue figures for friendly troops and red for the enemy, colors that are still used today.)
• Commanders, on all levels, were encouraged to continuously assess the situation, and adjust their plans accordingly. To adjust was more important than to follow orders. One could in fact be reprimanded for following orders, if it meant that opportunities were missed.
  

The social network led to ad hoc collaboration on the battlefield. Intelligence and war game experience led to better, more informed decisions. Command culture led to exploiting enemy weaknesses and countering their strengths, dynamically, on the battle field.

During the second half of the 19th century, the Prussians were invincible.

part 4

Everything in a Single File

You may have noticed that I prefer to write my Scala examples as a single listing, I also only use what is built into Scala, no third party libraries.

The advantage for me is that I don't have to find some other place to host the code, and it saves me the trouble of having to explain how to set things up in order get the code to run. The advantage for you, the reader, is that you can simply copy and paste into a xxx.scala file in your Scala IDE or editor of choice, compile, and expect the code to work (at least if you use the same version of Scala as I do).

The downside is that I may have to roll my own implementations of readily available components, and that the programming style will not lend itself to TDD. For the kind of toy projects I currently do, I think the trade-off is worth it, and creating my own components can be great fun. Not invented here syndrome, here I come :)

Of course, I won't go to extremes with this philosophy, a particular subject may require another approach.

Stay tuned for The Dysfunctional Web Server, my toy web server component that I'll use in future labs.

Prussian Generals - part 2, Carl von Clausewitz

Carl von Clausewitz served in the Prussian army, and later in the Russian army during the Napoleonic wars. Soon after the wars ended, in 1816, he started a work on the art of war. He never finished, instead dying from cholera in 1831. His widow published "Vom Kriege" ("On War") posthumously in 1832. Exactly how complete On War was has been hotly debated, but regardless it is considered to be the major treatise on the art and philosophy of war in the western world.

Some interesting points and concepts in On War are:

• Friction, things rarely go as planned when tiny problems accumulates. Roads are more difficult than envisioned, the weather is slowing movement, soldiers get drunk, and so on.
• Fog of war, commanders on all levels will have limited intelligence on which to act, and lack knowledge of the overall picture.
• War is the continuation of policy by other means. A phrase that has been misinterpreted as advocating war over politics, but what Clausewitz really means is that politicians must be the ones to decide if and when war is warranted, and what the goal of war is.

The first two points means that a commander must act and react swiftly on the information at hand. It is as necessary to adjust in the face of bad luck (or preparations), as it is to grasp opportunity when it presents itself.

The third point is important in that it means that war takes place in a context and, like it or not, politicians have a huge impact on how war is waged.

part 3

Prussian Generals - Overview

I gave a 10 minute presentation about the agile Prussian army at the last OpKoKo. It was well received, and I have considered sharing the slides, but they don't say that much on their own. Therefore I have decided to write a series of short blog posts with the gist of the presentation.

Since the series is complete, I put all parts in one post, go here to read it: Prussian Generals

(I will update this post with links to the various parts as they are published.)

1. Setting the Stage
2. Carl von Clausewitz
3. Helmuth von Moltke
4. Take a Step Back
5. Conclusion

)

Prussian Generals - part 1, setting the stage

Since the series is complete, I put all parts in one post, go here to read it: Prussian Generals

What can agilistas learn from 19th century Prussian generals? Not much, it would seem. But bear with me, all will be revealed.

But let us start at the beginning. The year was 1800, and the Napoleonic wars are in full swing. Napoleon had a pleasant problem, with too many soldiers to command. Reform was necessary, and he came up with the concept of army corps (Corps d'Armée). A corps was a mini army with its own infantry, cavalry, and artillery, and a fairly independent commander. All in all about 20-30,000 men. The general staff was used to help control all corps in the army. A general staff in the modern sense was a product of the French revolution, and Napoleon benefited enormously from its invention.

French army size at Austerlitz and Wagram

As Napoleon demonstrated the superiority of his style of warfare, other nations started to copy his and France' ideas. Prussia was an early adopter of the French ideas, and it was Prussia who would carry the torch after the demise of Napoleon.

part 2

Javaites won't do Scala

David Pollack writes "Scala use is less good than Java use for at least half of all Java projects". And I agree with his conclusion that

"Scala is an inappropriate language for the majority of Java developers and cannot be expected to replace Java because for at least 50% of Java developers, Scala's difficulty outweighs its value."

But it is dangerous to draw the conclusion that Scala isn't a suitable replacement for Java :-). I don't have the experience David has using Scala. I did however make the transition to object oriented programming in the late 1990:s while working at a large company, and I was responsible for Java technology at said company for a brief period of time.

When Java and Microsoft took over the world, it wasn't by replacing Cobol and RPG with Java and VB. Instead, new projects used these technologies, and there were ambitious programmers ready to man those projects. First came the r&d labs, followed by pilots, and years later, full scale projects. Most old school developers didn't learn Java until much later, some still haven't. But as time goes on, more and more old systems are retired, but more importantly, the number of new applications is exploding, swamping the number of old ones. And I don't believe we have seen the end of that trend.

So the future of Scala will not depend on if most Java developers transitions to Scala. It will depend on whether Scala can compete with other newcomers on the corporate scene.

One final thought, writing Java in Scala will not necessarily make projects fail, and is inevitable in a large company. The code will improve over time (with new projects), and the productivity gains realized, but it will take several years.

Scala is so very hard ... not

It is a bit tiresome to read about how hard Scala is to use. If Scala is hard, then so is every other modern language. Yes, even Java, the favorite language to compare Scala to. For old farts like me, the increased complexity has been gradual, but very real non the less.

When I started as a junior programmer back in the eighties, recursion was considered really advanced and difficult to grasp. A few years earlier, Ada was criticized for being too large and complex. A few years ago, Visual Basic came under fire for much the same reason. Progress is controversial.

So is Scala hard and complex? If you intend to use all of Scala, then it certainly is. But few people have the need to use all the nooks and crannies of a programming language. And we see many features only as consumers, not creators. For instance, when coding Java, I use generics a lot, but I rarely create generic methods. It's not needed for business applications.

The days when one could learn everything in a language lie way back in time. No longer can you judge complexity of a language simply by adding together the complexity of all the parts of a language. Judgement must be metered out in light of the intended application.

Scala is very easy to learn enough of to get started. The road from there may take you to easy or hard parts of Scala, but that's no different from other modern languages. If you need to code complex programs, it gets hard. (Of course, some things may be easy in one language, hard in another, but you can't escape essential difficulty.)

If you don't need to write DSL parsers, you can safely skip that part of Scala. If you find yourself in a project where it's needed, and you find it difficult to understand, Scala is the least of your problems.

If you don't write libraries or application servers, you probably don't need to worry too much about monads, currying or partially applied functions.

If you don't need XML... You get the drift.

To summarize, as a general programming language, Scala is easier than most languages. It has some features that could be considered hard, but just like Java, that's parts that's either not used in day to day programming, or that should only be used when the task is inherently difficult. Don't worry, be happy.