Monday, 26 October 2015

Another interation..

It's the end of a long weekend, and alas I was not running the marathon or partying like a rockstar. I was either building flat pack furniture for our forthcoming baby or working on my project for this class. The simple fact is that with a baby due in a few weeks, it pays to be ahead of the game. That I am. But this bit is always easy, throw loads of words at the page in some kind of roughly aligned organizational structure. But then I must spend the same about of time implementing grammar, referencing, getting below the word count. Oh what it must be if one was a professional writer, and you could "throw it over the wall" to an editor, or indeed a team of editors in my case :D [as developers are so keen on doing, throwing their dodgy code over to QA teams!]

The Microsoft case study for this week is interesting. But its nothing new to me, really. We look at three teams at Microsoft, they adopt a new practice and are diligent about it. They are monitored pretty closely. I think any team of skilled people, [..with the eye of Sauron on them] will do well working with practices which break out their work and have clear tasks like this.

On this week's readings, Kent Beck is this week's interesting fellow. He was one of the brains behind the agile manifesto [so I have read in a few places, but I hazard a guess that more than person has that said about them], and was one of the initial folks who put their name to it. Now we move onto one of his earlier papers dealing with Extreme Programming. In my working life XP is a bit of a joke, a term of derision. But what he is clearly doing is pulling good ideas from here and there, and making a new thing. Not unlike Henry Ford coping meat packing practices when he wanted a way to make more cars, and make them cheaper.

But if you read what he is actually saying it's the direction a lot of software companies have gone. They work on loads and loads of small iterations. They want to get the software to their production servers as often as possible, many times a day if you are doing it right. You design, code, build, test and then deploy many tiny things, rather than big huge monolithic things [as Waterfall tended to do]. That way, if your Microsoft working on Office 365. You have a story to take advantage of 3D printing or something like that. You design that one thing in isolation. You get the team to code it. Then you release said enhanced printing function without having to patch a billion copies of office, or doing another release or something. You make your enhancements, release when it's ready, patch your host servers and you are done. Customers have enhancement. Back 5 or 10 years ago, that would be a feature lost in a big bang version of office which hit your desks every 3 or 4 years.

2 comments:

  1. On the subject of writing. Don't forget the Appendix. Fill it up, put your left overs and orphan sentences, data, etc. there.

    ReplyDelete
  2. Ah right. The good old "Hawthorne experiment" explanation. Improvements come about due to the simple device of paying attention to what people are doing...

    ReplyDelete