LinkedIn | FaceBook | Twitter
I’ve mentioned before on this blog a little about how we write software here at Microsoft. I think it’s great that we are allowed to talk about it – in fact, we’re encouraged to be open about it. That’s very different from many other software firms I’ve dealt with. Along with describing how we write software, I thought I would share a very simple philosophy I have on the process. I’m not talking about Agile, or any of the dozens of other methodologies, since those normally deal with the mechanics of the coding process. I’m staying a bit more broad than that, with a bit less detail. For me, the process to writing good software has three attributes:
This might sound obvious, but in fact it isn’t. We get lots and lots (I get several thousand just in my area) of suggestions for what we write for software. Since we write the various SQL Server components, as a group we also think we know a few things about the software we should write to manage it. But just coming up with a great idea isn’t enough. I’m sure every developer in the world has been faced with a request that just isn’t possible or advisable. When I design our management tools I have to keep a lot of things in mind, such as:
So whatever feature I dream up has to pass by these gates to get done properly. So when I design, I don’t just think up new and interesting ways to do things – I have to create something the dev elopers can actually pull off.
People move around a lot here. It’s very common to see developers, Program Managers (like myself), testers, authors and others on the project move on to another part of Microsoft or even other companies after their feature is complete. That turnover is healthy, since I routinely get new developers from games, office, Windows, the Live team and so on. They get our developers as well. Along the way we get some great cross-pollination. But it can come at a great price if the software the first dev write isn’t easy for the next one to maintain. One thing I have noticed in SQL Server is a great code review system. When a developer writes code, he or she passes it around (using Visual Studio Team System) to one another to look over. Even the Program Managers are asked to look at the code. Since we all know we might be supporting someone else’s code someday, we make sure that anything we write is modular enough and understandable enough to support later.
The first two thoughts are for us - this is where you come in. We can have the best processes in the world, we can have the most maintainable software on the planet, but if you can’t use it, we can’t sell it. True, we’ve made our mistakes, but by and large the management tools for SQL Server are a lot better than other things you’ll find out there. And we have a lot of people that work hard every day to make it better.
Well, that’s my 2 cents. I’d love to hear your thoughts on how you write quality software – I might just learn a thing or two!
I’ve mentioned before on this blog a little about how we write software here at Microsoft. I think it
I might append something like "separated" to your list. One of the biggest challenges with using software seesm to be the "tied to" elements. Simple example, SSMS has a few warts, and they don't seem to be addressed rapidly because they are bound up with warts somewhere else in the system. Treating UI like skins, separated from the underlyting layers discretely, would mean that you could enhance usability much more easily over time.
In a less awkward way, I guess what I'm talking about is that really great software should, to some extent, be written with a degree of separation in mind, to prevent the kind of forced compliance that hampers adoption, or slows end-user acceptance. (Best example I can think is Visual Studio tools, where I have at least 2 versions installed because the frameworks are tied to the development tools. When designing the tools, planning not to have that happen is a useability issue.)
As I reread that I think, "It's way too late/early for rational thought, but what thehey. " ;-)