Bill Gates: less code is only metric
By Ryan Tomayko under Then you win. on 20. September 2005Gates had this to say in a recent interview with Jon Udell.
“There’s only really one metric to me for future software development, which is — do you write less code to get the same thing done?”
I’d be lying if I said that didn’t put an immediate grin on my face.
I personally don’t get that feeling from Microsoft’s present toolset but I’m interested in understanding this situation better. I’ve been impressed by their ability to resist being sucked into much of the Enterprise hype that seemed to drive J2EE to bloatedness, but “less code” as the metric for innovation in development tools and methodology? Is there really a strong concious regard for simplifying things in Microsoft’s developer culture?
I’ve had this in draft for a few days because I wanted to talk a bit about the false assumption that GUI = simplicity (not saying that’s what is going on here but it is a falacy MS has subscribed to in the past). But now Michael Champion, who is one of the very few reasons I have left to respect MS’ technology, is beating up on us for a comment.
So bravo to Gates and all that but is it true and does Gates’ personal view on simplicity trickle down into the trenches at MS?
Via Tim.
Pramod Biligiri:
Maybe it’s only incidental, but the LINQ project(http://msdn.microsoft.com/netframework/future/linq/) definitely seems like a step in that direction. Less code and fewer concepts in the app domain, more work put in the language spec and runtime.
And yeah, even I thought of this very same site when I read that part of the interview
comment at 20. September 2005
Anthony Francis:
True “Microsofties” have always been on the less-code-is-more bandwagon. The best programmer I know, bar none, is an old-school C++ hacker who actually participated in the development of Windows NT as a contractor … but who switched to Visual Basic about five years ago. Why? Summarizing two or three conversations:
The key to exploiting the Microsoft code advantage? You actually have to drink the Kool-Aid and use the Microsoft tools in a Microsoft environment the way that they’re designed - that is, get a subscription to MSDN and learn its contents. If you do so, what you’ll probably find that for most of the problems that you’ll encounter, there’s a preexisting component or wizard that will get you 90% of the way to a solution without writing any code other than the name you want your framework app to be called.
-Anthony
P.S. I develop Java/Python/Lisp for a living, and don’t drink the Microsoft Kool-Aid … but I see the sunny looks on the faces of developers who do.
comment at 20. September 2005
alexbunardzic:
Similar to how Rails is opinionated, so are Microsoft tools. That is to say, they are, in a way, a brand of domain specific language. And hence the ability to lesscode one’s way through them.
But on the flip side, their domain is Microsoft desktop. So, if your world revolves around that beast, more power to you. But if it doesn’t, then you’re in for some pain.
Take InfoPath, for example. It proposes a way to build web apps using a familiar desktop-centric paradigm. How solid will those app end up looking and behaving? You be the judge.
So yes, InfoPath is very opinionated. Which means that it makes it incredibly easy to build desktop-centric apps, and almost impossible to build any other types of apps. The unfortunate thing is that the lines are somewhat crossed. Sort of like trying to build a high resolution video game in COBOL.
comment at 20. September 2005
Mike Champion:
Pramod Biligiri beat me to it - the main evidence in favor of the proposition that billg is a closet lesscode.org supporter is LINQ. I’m too new and unconnected to really know how deep the conscious regard for simplifying things goes in the MS culture, but consider: Whatever you may think of MS, they are not known for hiring dummies. Smart people learn from their mistakes, other peoples’ mistakes, and other peoples’ successes. Let’s just say that things like C++, XML Schema, the time it has taken to get the 2005 and 2006 wave of products near completion … and at the same time the rise of Web-based apps and dynamic languages … has given people here lots to think about. I can’t swear that the lesscode philosophy runs rampant here, but the former self-confidence that complexity works in favor of those with the resources to hide it behind a nice GUI seems to be on the wane.
Speaking of Visual Basic, it was just fascinating to watch Erik Meijer (a key developer of Haskell and other bleeding edge languages) get hooked on VB, and watch the VB people work with Erik to apply their traditional “lesscode” approach to XML.
I think this all points to a future where the old “simple code or powerful tools” debate is moot. Simple code AND powerful tools takes us somewhere neither can go alone. I know I almost fell out of my chair watching Anders Hejlsberg demo LINQ in Visual Studio, and he said something like “see, this looks just like script … but it also has all the power of strong typing behind the scenes.
comment at 20. September 2005
Ryan Tomayko:
Anthony: Indeed. Safety is nothing if not comfortable. :)
On the topic of Kool-Aid, it seems that one of the perceived benefits of drinking it and accepting a less-free set of tools is that you’re buying a bit higher threshold for acceptable complexity. That is, technologies like COM, OLE, WS-* can be modestly more complex at Microsoft because there’s an authoritative source saying “this is the technology you must use”. I just think that’s kind of interesting when compared to the F/OSS (and LAMP/friends especially) situation where tools must have a basic level of simplicity as a prerequisite for adoption by the ecosystem.
So you have to ask yourself, what are the stated benefits of simplicity? My primary argument for simplicity is adoption. That is, simple technologies are easier to adopt and are therefore more likely to be adopted. There’s obviously a whole slew of other benefits of simplicity around maintenance/management but I wonder if certain situations wouldn’t be considered differently in the F/OSS and web worlds as opposed to by someone at Microsoft.
Let’s take SOAP and WS-* for instance. In a great majority of cases, simple POX/REST styled solutions are much less complex than a full-on WS-* solution and provide the same level of functionality (I didn’t say all cases, I said most). So anyone can play. On the other hand, Microsoft can standardize on WS-* and integrate it deep into their language so that the additional complexity is hidden to the point that its no more complex for developers using compatible tools than POX/REST. (This is the basic premise for how SOAP/WS-* could actually be viable: they must be hidden.) Here we have a situation where simplicity is placed below completeness in priority because toting around the additional complexity of things like XSD typing, “discovery” (WSDL), and the mess of other crap is supposedly contained. Anyone can play - so long as they have MS tools as a baseline.
And I do realize that standards bodies are the supposed solution for allowing other tools to play as well but that’s not working. Some believe it’s primarily because MS doesn’t play nice with compatibility but there’s a more fundamental reason for this: the world (outside of Microsoft) is bound by simplicity. You can ratify complexity into standards all day long and it won’t change that. Standards must be driven by observed interest and adoption, they are rarely capable of causing it.
comment at 20. September 2005
Bill de hOra:
Mike,
“I’m too new and unconnected to really know how deep the conscious regard for simplifying things goes in the MS culture, but consider: Whatever you may think of MS, they are not known for hiring dummies. Smart people learn from their mistakes, other peoples’ mistakes, and other peoples’ successes.”
Yes. Perhaps the problem with some really smart people is that their pain thresholds for complexity are set too high.
“I think this all points to a future where the old ’simple code or powerful tools’ debate is moot.”
And not a decade too soon. What LINQ suggests to me is that your language designers are starting to think beyond OO for the trenches (we all know they think beyond OO for everything else). That could have a major effect in the SI and PS sectors a few years out. I would love to see what the enterprise and solutions crowd in MS make of LINQ - has Ward Cunningham seen it?
comment at 20. September 2005
David O'Hara:
I have to question what constitutes “less code”?? Obviously, if implementing the exact same thing in one language takes less LOC than another - that’s less code but if the first language simply has everything abstracted into a “standard library”, is that really less code?? As a “true Microsoftie”, I love the fact that the .Net framework has so much built into it and at my disposal but I’d be hard pressed to say that it falls into my idea of a “less code” language like Ruby does.
*braces for flaming from MS friends*
comment at 20. September 2005
Bill de hOra:
“In a great majority of cases, simple POX/REST styled solutions are much less complex than a full-on WS-* solution and provide the same level of functionality (I didn’t say all cases, I said most). So anyone can play. On the other hand, Microsoft can standardize on WS-* and integrate it deep into their language so that the additional complexity is hidden to the point that its no more complex for developers using compatible tools than POX/REST.”
In fairness, we should point out the J2EE world has its own tool fetishes; JSF is a good example of a (very recent) J2EE technology designed (implicitly or otherwise) to be manipulated with tools.
There’s also thinking about simplicity as being something that gets distributed over time. Simplicity/complexity permathreads often come down to a technology being simple at a particular stage in some ‘lifecyle’, but more complex in others; people’s definition of simplicity tends to focus on what part of a software lifecycle they care most about and how much much simplicity has been ‘distributed’ there. PHP is good example. PHP has a lot of simplicity at the beginning of a development. OO/Enterprise types don’t like the idea of dealing with PHP spaghetti for maintenance, and would prefer what they see as more structured and manageable approach for development, which takes simplicity out of early development and moves it elsewhere. But then OO/Enterprise types have a tendency to leave behind operationally complex systems where very little simplicity is left over for day to day management. In user interfaces the learning curves for CLI and UI approaches that people like to compare indicate a kind of complexity/simplicity distribution. In the XML community I see this when people refer to the alledged benefits of some technology requiring an upfront loading of costs as “tax”.
Incidentally, Mike Champion is a good bet to write the definitive piece on complexity conservation over time someday ;)
comment at 20. September 2005
inglorion:
I just wanted to add that having extensive frameworks and/or a domain specific language aren’t the only ways to get more productivity out of your code. Having a flexible language helps, too, and is arguably the best approach. It allows you to quickly write extensions, or even adapt the language to a domain that the designerd hadn’t thought of.
Things that help in this respect are low-level primitives (you can write something equivalent to call-return given goto, but you can’t write goto given call-return), first-class functions (passing functions as arguments is very powerful), macros (as in Common Lisp), and call-with-current-continuation.
comment at 21. September 2005
Mitch Barnett:
I have been a lurker for a month or so when my fellow co-worker pointed out lesscode.org to me. Cool site! After reading this latest entry and comments, I can no longer lurk.
Isn’t the whole point of lesscode.org is to indeed write less code? Or am I missing something? So far, most of what I see is comparison of programming languages or technologies and how one is better than the other or more extensible, etc. What does this have to do with writing lesscode?
I appreciate Anthony’s comments about VB and why the C++ hacker went the route he did. It is absolutely true – been there, done that. While I have spent many years writing LOC in assembly, C, MacApp, Objective-C, J2EE, .NET, blah, blah, and even though I am a Smalltalk bigot, I make my living in the Microsoft world and the only kool-aid I drink is Guinness :-)
If you really want to talk about “less code”, how about thoughts and discussions on using code generators or visual language tools like Domain Specific Languages. Not only is this about less (hand crafted) code, but also about the process of predictability and repeatability in an industry that still lives in the dark ages. As far as I am concerned, we still use hammers and chisels to carve out our code. Meanwhile, other engineering disciplines have industrialized themselves using advanced code generation tools like AutoCAD. Think about it – that’s what AutoCAD really is.
Software industrialization is close to my heart, so close you can read about it here: http://softwareindustrialization.com
My hats off to your lesscode.org site, as I see it, you and your crew are indeed driving the industrialization of software. Kudos!
comment at 23. September 2005
Ryan Tomayko:
Mitch said:
Right. I’ve had this same comment in email - “more show, less tell”
I think a lot of what we’ve been concentrating on are indeed techniques that result in less code, less complexity, etc. For instance, Ruby/Python/PHP, REST, Microformats, etc. all seem to require much less complexity and code than many of the tools and technologies that are currently industry mainstream. When I say “industry”, I’m referring to the “Enterprise Software” industry. I don’t have a heavy web background, I’m not a designer. I grew up in The Enterprise and I’m familiar with the tools and technologies that are mainstream there.
What I’ve been finding on the web is that most of its common infrastructure is extremely relevant to business IT and they (business IT) are ignoring it. So this place can spiral into a rant fest pretty quickly because there is a debate going on. I don’t only want to show cool stuff but show it in the context of existing business IT.
But I do take your comment to heart and I’m making a concious effort to move my focus away from the debate and more towards illustration of what I’m finding with these technologies, tips for making them work, and community resources. We’ve chinked the armor and turned some heads in the past few years. I’m personally growing bored of talking. For me, all this adds up to trying to get on to the “Next Phase”, which is bringing the communities together and putting some more flesh on the individual technologies.
Unfortunately, I have lots of ideas and very little time at the moment. I’m also coming up to speed with some new technology so I haven’t felt as comfortable as I’d like to be able to offer up valuable content in the form of projects or tutorials. I’m coming up over the hump now and things are starting to come together. Like I said, I have a ton of ideas for this place and I’m just waiting for some spare time.
Truly appreciate the comment, Mitch.
comment at 23. September 2005
Bill de hOra:
Mitch: “If you really want to talk about “less code”, how about thoughts and discussions on using code generators or visual language tools like Domain Specific Languages.”
I’m sitting on a DSL post; I can’t quite seem to get it to hang together, but I can boil it done to this essence:
start with a full scripting language and constrain as needed, rather than designing your own language and extending as needed. Outright language design is too hard in real world delivery timescales.
the DSL revolution, come the glorious day, will be linguistic, not visual. This is where the CASE/BPEL tools go awry.
But hey Mitch; wanna post something here? Ask Ryan for an account.
comment at 23. September 2005
Ryan Tomayko:
Bill: I’m anxiously awaiting that post. :)
On that topic, I’ve been waiting for someone to make the point that LINQ shouldn’t require changes to the core language. Given a language that allows highly expressive DSLs to be created, LINQ should be able to come as library.
I haven’t looked into LINQ very deeply so I might be talking out of the side of my mouth here but I’d love to see someone brainstorm on how something like LINQ might be done in a Ruby DSL. Not the actual implementation but what the DSL would look like.
comment at 24. September 2005
Bill de hOra:
“LINQ might be done in a Ruby DSL. “
Ohh! As if I haven’t enough distractions already. Can you set up a svn repo? If not I’ll create one on textdrive.
comment at 24. September 2005
Ryan Tomayko:
:)
I’ll see your svn repo..
svn://lesscode.org/rubyq/trunk
and raise you a trac instance:
http://lesscode.org/projects/rubyq
subversion auth is on the way…
comment at 24. September 2005
Robert Church:
On the subject of implementing something like LINQ in Ruby, have a look at Criteria.
It’s a library intended to let you write composable SQL queries in-line in Ruby, using some clever abuse of operater overloading. I don’t think it’s really complete, and I don’t think it’s maintained, but the basics are there.
In the same vein, there’s Avi Bryant’s Roe system for Squeak, which appears to be breathtakingly simple and powerful.
comment at 26. September 2005
Gosling Didn’t Get The Memo [@lesscode.org]:
[…] I’ve been blissfully neglecting this site for months with the assumption that a large part of our goal was completed. After watching good people like Martin LaMonica and Jon Udell balance out the mainstream tech press with coverage of lessish tools and languages, and having seen forward looking companies like RedMonk inject themselves into the traditional analyst racket with smart, honest, and unignorable critique, and having seen herds of Java luminaries migrate to simpler, more agile tools and languages, and after hearing Bill Gates say that less code was the only metric, and having watched David, Bill, Ian, Adrian, Phillip, Aristotle, Harry, Mark, Mark, Chad, Curt, James and many other extremely talented programmers dismantle all the common hollow arguments for superfluous complexity and replace them with simple methodologies and working code, after all that I just figured there wasn’t much to do around here. […]
pingback at 12. March 2006
Thought Leadership:
Why Ruby Doesn’t Matter…
You may have noticed that pretty much everyone in the Ruby camp are insultants with many of them being book authors attempting to capitalize on hype. I of course, will remain open minded that Ruby may be better than say Java at some tasks but for the…
trackback at 13. March 2006
Less code is the only metric » The R Zone:
[…] Over at lesscode.org (Bill Gates: less code is only metric [@lesscode.org]), finally, a comment from Bill Gates I wholeheartedly agree. There’s only really one metric to me for future software development, which is — do you write less code to get the same thing done? […]
pingback at 14. March 2006
appletree » Blog Archive » Bill Gates Champions Simplicity:
[…] I think most people intuitively embrace this ideal, but many still wonder whether it is reflected in Microsoft’s products. Lesscode.org has more, and a link to the interview. […]
pingback at 17. March 2006
Thought Leadership:
More Thoughts on Ruby and Why it isn’t enterprise
I previously blogged on Large Enterprises and why they don’t care about Ruby and was rightfully accused of bashing folks in the Ruby community but not providing the answer to my original statement. Figured I would set things right…
trackback at 18. March 2006