3 ms·

An assumption? We've been told pretty directly how complicated the process is (often with pride). See the 14 steps which turn a 5 minute code change into a mul

by latch 16y ago

An assumption? We've been told pretty directly how complicated the process is (often with pride). See the 14 steps which turn a 5 minute code change into a multi-man-month-mammoth: http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298... Or the now infamous Windows Shutdown "crapfest": http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c... There's more. And I have no problem with the author stating how great coding is (because he has an office and a nice computer!). However, while your right hand is telling us how great it is and we shouldn't assume otherwise, your left hand is telling us how horrible it is.

kulkarnic 16y ago
Well, you are confusing "complicated" with "difficult". While this is true in general, automation reduces the difficulty of working with a complicated system. For instance, the build system is extremely "complicated". But all you really need to do is to make sure your code compiles, you pass all your local tests, and the BVTs, and you are good to go (oh, and a code review; anyone who objects to a code review is probably shouldn't be coding). When, you, as a developer, satisfy those local conditions, the system automatically works at the global level. Don't get me wrong, complexity is an evil that I'd rather avoid, but it is a necessary evil for creating systems that are useful in the real world; and it is an evil that can be tamed with automation. [Full disclosure: as a former MSFT employee, my thoughts are heavily influenced by the company.]
- rbanffy 16y ago
  > automation reduces the difficulty of working with a complicated system. Effectively preventing it from ever being simplified. Like you said, complexity is evil and has to be addressed because no amount of automation will correct it.
andywood 16y ago
This blog post is mainly about the tools developers use day-to-day while they're in coding mode. Tools and development processes do tend to be well thought out and efficient at MS. That's not really related to the organizational dynamics that come into play for planning products and features. That tends to be complicated, involving a lot of people, meetings, and debate. (I'm not defending it, just saying that's how it is.) That 14 steps isn't about a code change; it's about the end-to-end design, implementation, and shipping of a feature, expressed in the most detailed, far-reaching way possible, to make a point about how things operate in a huge organization. Both points of view are accurate, IMHO. When you're strictly coding, things are pretty efficient. Not too surprisingly, those were the times I enjoyed the most. But it's equally true that at MS, coding is only a small piece of a larger, somewhat slow-moving process. And sure, all that other overhead can get tedious, even exasperating at times. It's just a separate subject from what the OP is writing about here. The coding part is typically quite fun and autonomous.
- latch 16y ago
  I don't mean to drag this out, since I largely agree with what you are saying, and it's true that the OP seems to focus on that. However, his intro blurb specifically says that we are wrong in assuming that writing software is a "soul-crushing bureaucratic exercise." Which, as you point out, the post never really says anything more about.
  - jasonlotito 16y ago
    Remember, the intro blurb is discussion all the articles he intends to write on the subject. Together, they intend to show you how the intro is true. As it stands, he has two articles on the topic. Most people are only reading the one (the one which is linked). Even in that, the introduction is a common introduction for all the pieces (the two so far, so I imagine the others as well). That the original article focuses on coding doesn't mean he's ignoring other areas. Rather, that other areas simply haven't been written about.
paulcam 16y ago
I think you might be misinterpreting the first post you linked. He's not bragging about how complicated it is. He's also not complaining about how tricky it is. There are always things in the Windows org that could use improvement (otherwise, I'd be out of a job). However, the vast majority of processes exist to fulfill requirements that very few software projects have to deal with. Consider that Windows ships in over a hundred languages to hundreds of millions of people. I'm not sure how many languages Linux ships in (I'd bet quite a few), but Linux contributors don't have to worry about getting arrested for drawing map lines wrong: http://blogs.msdn.com/b/alexbarn/archive/2004/08/20/217602.aspx http://blogs.msdn.com/b/alexbarn/archive/2004/08/20/217602.a... Do we ship software without testing? No. Do we ship software that isn't globalized? No. Do we just hack something together, check it in, and call it a day? No. These aren't the kinds of practices that lead to a stable platform. Mistakes get made (at all levels of the management chain), but they tend to be the exception in my experience.
bkhl 16y ago
Those blogs were posted in 2003 and 2006. We are in year 2011. 5 years in tech industry is like 20 years in other industries. Just sayin'

by latch 16y ago

kulkarnic 16y ago

Well, you are confusing "complicated" with "difficult". While this is true in general, automation reduces the difficulty of working with a complicated system. For instance, the build system is extremely "complicated". But all you really need to do is to make sure your code compiles, you pass all your local tests, and the BVTs, and you are good to go (oh, and a code review; anyone who objects to a code review is probably shouldn't be coding). When, you, as a developer, satisfy those local conditions, the system automatically works at the global level. Don't get me wrong, complexity is an evil that I'd rather avoid, but it is a necessary evil for creating systems that are useful in the real world; and it is an evil that can be tamed with automation. [Full disclosure: as a former MSFT employee, my thoughts are heavily influenced by the company.]

rbanffy 16y ago
> automation reduces the difficulty of working with a complicated system. Effectively preventing it from ever being simplified. Like you said, complexity is evil and has to be addressed because no amount of automation will correct it.

andywood 16y ago

This blog post is mainly about the tools developers use day-to-day while they're in coding mode. Tools and development processes do tend to be well thought out and efficient at MS. That's not really related to the organizational dynamics that come into play for planning products and features. That tends to be complicated, involving a lot of people, meetings, and debate. (I'm not defending it, just saying that's how it is.) That 14 steps isn't about a code change; it's about the end-to-end design, implementation, and shipping of a feature, expressed in the most detailed, far-reaching way possible, to make a point about how things operate in a huge organization. Both points of view are accurate, IMHO. When you're strictly coding, things are pretty efficient. Not too surprisingly, those were the times I enjoyed the most. But it's equally true that at MS, coding is only a small piece of a larger, somewhat slow-moving process. And sure, all that other overhead can get tedious, even exasperating at times. It's just a separate subject from what the OP is writing about here. The coding part is typically quite fun and autonomous.

latch 16y ago
I don't mean to drag this out, since I largely agree with what you are saying, and it's true that the OP seems to focus on that. However, his intro blurb specifically says that we are wrong in assuming that writing software is a "soul-crushing bureaucratic exercise." Which, as you point out, the post never really says anything more about.
- jasonlotito 16y ago
  Remember, the intro blurb is discussion all the articles he intends to write on the subject. Together, they intend to show you how the intro is true. As it stands, he has two articles on the topic. Most people are only reading the one (the one which is linked). Even in that, the introduction is a common introduction for all the pieces (the two so far, so I imagine the others as well). That the original article focuses on coding doesn't mean he's ignoring other areas. Rather, that other areas simply haven't been written about.

paulcam 16y ago

I think you might be misinterpreting the first post you linked. He's not bragging about how complicated it is. He's also not complaining about how tricky it is. There are always things in the Windows org that could use improvement (otherwise, I'd be out of a job). However, the vast majority of processes exist to fulfill requirements that very few software projects have to deal with. Consider that Windows ships in over a hundred languages to hundreds of millions of people. I'm not sure how many languages Linux ships in (I'd bet quite a few), but Linux contributors don't have to worry about getting arrested for drawing map lines wrong: http://blogs.msdn.com/b/alexbarn/archive/2004/08/20/217602.aspx http://blogs.msdn.com/b/alexbarn/archive/2004/08/20/217602.a... Do we ship software without testing? No. Do we ship software that isn't globalized? No. Do we just hack something together, check it in, and call it a day? No. These aren't the kinds of practices that lead to a stable platform. Mistakes get made (at all levels of the management chain), but they tend to be the exception in my experience.

bkhl 16y ago

Those blogs were posted in 2003 and 2006. We are in year 2011. 5 years in tech industry is like 20 years in other industries. Just sayin'