Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
Our thoughts on making great software
As long as I’m picking on Microsoft for releasing developer tools before they’re fully baked — a cornerstone of Microsoft strategy, according to Joel Spolsky — I might as well take a swipe at their laughable not-quite-a-wiki.
At the bottom of most pages on MSDN is a section called “Community Content”. It’s the Microsoft’s way of encouraging participation from the developer community. Ever since Steve Ballmer skipped onstage chanting developers, developers, developers, developers, Microsoft has tried to recapture the attention — and most importantly, the talent — of the independent developer community. Most of those developers have long since fled to other platforms. Most of these alternatives are open source, meaning that they’ll accept contributions from any programmer with a good suggestion.
This is important, because before most good programmers get their first job, they’ll begin contributing to open source projects. It’s a way to gain experience and confidence, while helping to build their resume. Once they enter the working world, they’re likely to stick with the open source technologies they know. Microsoft is painfully aware of this, and not quite sure what to do about it.
Hence the Community Contribution section on MSDN and Microsoft’s recent open source initiatives. It’s their attempt to bring back the magic and infuse their technologies with teh awsum. While they’ve done a great job with CodePlex, and there’s a healthy Microsoft blogging community of consultants, partners, and independent developers, Microsoft suffers many of the same difficulties switching to an Enterprise 2.0 mindset as other large corporations.
So, you’re a developer, and you’ve found an oddity — possibly a bug, definitely a surprise — in one of the .NET framework’s gazillion objects. Naturally, after exhausting all other avenues for help, you found yourself (shudder) actually reading the documentation on MSDN. Unsurprisingly, it makes no mention of the quirk. You think to yourself, hey, maybe I’ll leave a note using this Community Content thingy. So you click the “Add new content” link and see the following screen.
How many problems did you spot? OK, the image is a little small. I’ll enlarge and highlight a few things.
First, if you’re trying to encourage participation, never, ever, say that this is “not the right place”. If someone wants to make your website better by adding detail, let them. If it turns out that the contribution is not relevant, you can always edit, move or moderate it later. And if you must point out that another forum or communications channel is more appropriate, at least be so good as to provide a hyperlink to it. This is the web, after all.
Second, don’t scare your users with legal threats. They won’t work. The nice users won’t contribute to your site out of fear, and the obnoxious jerks will post whatever they want anyway. It’s self-defeating.
And did you spot the third, final problem? This one’s tricky.
There it is: I’m already signed in to MSDN. They know who I am. I’ve agreed to their terms and conditions once already. They can ban me from the site if I don’t behave. Or they can leave my inappropriate post right where it is, so that everyone will know what an obnoxious jerk I can be. This entire page is nothing but a waste of time.
I could have said something incredibly useful. But hey, I’ve got important things to do. I don’t have time to read through another Microsoft EULA, thanks. Instead I’ll just get back to work.
When I was starting out as a Software Project Manager, A Zen Master taught me something that I never forgot. It happened when I was complaining about the lack of process behind the development team that I had just inherited.
I was younger then, and was frantically trying to introduce more structure to the way that my team shipped software. I could see a lot of the reasons for the product delays and the quality assurance failures. I just wanted to help. I had policy documents, and process plans, and Gant Charts. Lots of Gant Charts. But every effort I made to modify the process was met with stony resistance. In conversation, people could see that I was making sense. They would agree that yes, things were broken, and they probably shouldn’t be.
And yet I couldn’t get them to change anything. That was when the Zen Master appeared:
Me: “Grrrr! These guys are just making it up as they go! Everybody is just sitting around waiting for the developers to be finished. No wonder everything is so crappy and full of bugs. There is no structure or process here! ”
Zen Master: “You are wrong. There is structure.”
Me: “???”
Zen Master: “Structure comes in two states: implicit or explicit. You are complaining because there is no defined structure. Particularly no structure that has been defined by you.”
As is so often the case in fantasy Zen Stories, the master was right!
There was plenty of structure to the way people worked. It had grown organically based on the way that people wanted to work. It was hard to describe, and it was optimized more for individual happiness than for productivity, but it was there.
It dawned on me then that the best way to effect change was to embrace the practices that were implicit.
This kind of thinking led to Agile Practices. It led to Extreme Programming.
And it is the central premise behind Enterprise 2.0 or Social Productivity software. Harnessing the implicit structure of an organization can be the best way to improve it. People are innately social. They like to talk. They like to discuss things. They like to achieve things. They like to share. They like to boast.
It turns out the easiest way to get things done is to optimize the way people innately tend to do them.
Incidentally, If your PM is complaining about a lack of processes, it means that she can’t effectively bring about the cultural change that is required. You should either give her more authority, or hire a new PM. Or you could see if you can rustle up a Zen master to change her mind. 
Brad Feld at Feld Thoughts posted a slide by Adam Smith relating the Southpark underpants gnomes to pitching venture capitalists. The slides were meant to demonstrate how not to sell an idea to a venture capitalist. I understand the point, but I think if venture capitalists find themselves listening to gnome-like business plans they themselves are partly to blame.
Brad’s posted the clip from the Southpark episode, so I’ll just give a quick recap of the gnomes’ three phase plan:
The hardest part of any startup is figuring out Phase 2. Phase 1 is easy; it’s doing what you do best. For a software company, that means making software. For an author, it’s writing a book. For an artist, it’s creating art. Phase 3 is the goal: Making money, achieving fame, winning awards, etc. Phase 2 is the trick: finding a way to get from doing what you do best to the ultimate goal.
Often, someone starting out has only the talent and the dream. Figuring out how to make the dream a reality is a combination of hard work and dumb luck.
The idea behind venture capital is not simply to give new startups access to seed money. There are plenty of ways to raise funds. You could take out a business loan, put a second mortgage on the house, or hit up friends and family for cash. Part of the reason why startups turn to a venture capitalists is to get the benefit of their experience with other startups. In other words, it’s to get help with Phase 2.
Many of the current Web 2.0 darlings succeeded without any sort of business plan at all. YouTube was losing money hand over fist and had several copyright infringement lawsuits pending when Google rescued them. Google themselves nearly went broke before they hit upon the advertising formula that powers the attention economy. Facebook hasn’t figured out their model yet. Twitter has no means of visible support beyond VC backing. With these examples in mind, it’s hard to blame startup founders for glossing over Phase 2.
Yes, build it and they will come is the call of hopeful idealists everywhere. But boundless optimism is a necessary requirement for an entrepreneur. It goes with the territory. Venture capitalists, of all people, should appreciate that.
Those of you with a technical background may have noticed a close correspondence between the Web 2.0 principles I described in our design series and Representational State Transfer, or REST. This is no coincidence. Gordon’s been a backer of RESTful approaches to web application design for some time now; I’m a more recent convert. More importantly, the REST architectural pattern fit what we were trying to do with our infovark project.
REST is a design pattern used to create Internet applications. It’s been growing in popularity, but hasn’t been fully adopted by any of the major vendors yet. (Microsoft’s efforts to lump REST into the Windows Communication Framework notwithstanding.) This is probably due to the fact that the World Wide Web Consortium, or W3C, put its weight behind an earlier, competing design philosophy called SOAP. (SOAP used to stand for Simple Object Access Protocol, but the “simple” part was dropped long ago.)
SOAP was designed to help loosely connected computer systems communicate with each other. Many previous frameworks and standards had attempted to do the same thing, but with so many different hardware and software vendors building systems, most were doomed to fail. SOAP is likely to stick around for a while due to its close association with with Web Services and Service Oriented Architectures. As a practical matter, however, the class of problems that SOAP solves are actually rather limited. Strike that; the class of problems that only SOAP can solve are rather limited. For most applications, there’s an easier web services alternative: REST.
Pardon me while I geek out for a moment.
When I was a kid, me and my friend Rajeev would dial each other up — yes, literally dial each other — with our 300 baud modems. I know, I know, you young ‘uns are thinking, “What’s baud? What’s a modem?” Suffice it to say that it was a slow way to get two computers to talk with each other. And when I say slow, I mean S… L… O… W. You could literally watch the letters appear one by one in your monochrome terminal window. If you can imagine sending a message via Twitter one letter at a time, you’ve got the idea.
It was so painfully slow that there really wasn’t much point in sending messages back and forth. Other than the nerd-cool factor of making two computers located in different parts of town communicate, there wasn’t much to do. So Rajeev and I hit upon an idea. We’d play a game online. Being nerds, we naturally picked Chess.
Chess was actually a great application for modem-to-modem communication. There was a well-known initial starting state in the traditional arrangement of the pieces. There was an established protocol: white moves, then black moves. And there was even a short messaging format: chess notation.
So we started playing Chess online. Each of us kept a small chess board by the computer. We slowly took turns typing out our moves to each other and updating our game boards: “P-K4″, “P-K4″, “Kt-KB3″, “Kt-QB3″ and so on. Not exactly riveting entertainment, but hey, we were doing something new and different.
Every now and then, we’d run into a problem. I’d get a message from Rajeev with a nonsensical move, or he’d get a message from me that moved a nonexistent piece. Then one or the other of us would see these letters slowly print across the screen: P… I… C… K… U… P… T… H… E… P… H… O… N… E.
We’d then try to figure out what had happened, based on the log of all the messages that went back and forth and the current position of the pieces on each of our game boards. Sometimes we were able to figure out the mistake. Sometimes we agreed to go back to the last time we picked up the phone to reconcile our respective chess boards. Sometimes we started over.
As you can imagine, this sort of troubleshooting got old fast. And it happened all the time. Eventually we gave up on trying to play by computer, and we just bugged our Moms to drive us over so we could play using the same board.
The point of the story above is not to establish my geek cred, but to offer an analogy.
In the early days of network computing, bandwidth was low, latency was high, and it was vitally important to make your messages as concise as possible. A wide variety of message formats and protocols evolved to respect the limits of early computers and networking technologies, all designed to get as much useful data packed into as little space as possible. It’s exactly like the chess notation Rajeev and I used. We could have sent snapshots of the chess board after each turn, but it would have taken hours to transmit a single move that way. All we really needed to know was which piece needed to move where. Using the shorthand, a single move — one procedure — could be described in just a few letters.
Though network computing technology has come a long way since then, the most common way for computers to talk with each other is still via Remote Procedure Calls, or RPC. Rather than describe the entire gameboard, computers just tell each other how to move the pieces.
If you’re wondering how computers handle mistakes or lost transmissions, well, a staggering amount of effort in computer science has focused on error detection and correction algorithms and secure transaction processing. Believe me, the last thing your credit card company and your bank want to do is pick up the phone to work out whose set of accounts is more accurate.
This is why data replication is such a huge problem. If you only transmit the moves to each other, you have to start from a known initial state. The chessboard at Rajeev’s house and my house had to match at the start of the game. It’s also why synchronization is a big deal. If the moves are sent out of order, all sorts of problems occur.
If, on the other hand, you could send pictures of the game board back and forth, a seasoned player could probably reassemble the images in something close to the right order. Better yet, if both players could look at the same board at the same time, then you’d never get out of synch.
This is the essence of the REST architectural pattern. It’s a little less respectful of network resources, but by transmitting the current state of the game at any point in time, you can simplify the amount of work you need to do to get two players to agree. Most of the transaction issues and handshaking protocols become unnecessary. The World Wide Web — hypertext over HTTP — works in a RESTful way, and it’s the most successful computer application ever built.
Enterprise 2.0 is about applying the lessons from the Web to the enterprise, so it makes sense that we should start with the core design principles.
Infovark’s been in operation for six months now. In that time, we’ve written more than 100,000 lines of code and posted more than 50 blog articles. But — we still don’t have a product yet.
By the original timeline we drafted in October 2007, we should be in Beta by now. So, it was time to take a good hard look at our schedule. We were harsh with our estimates. And when we looked at our projected workload, we were suitably scared. (I’m sure that if you aren’t at least mildly terrified by your software schedule, you really haven’t done it properly).
So, after taking stock of what we’ve done and what we have left to do, we’ll hit Alpha some time this summer. (We hope!)
What’s taking us so long? Well, for one thing, all software projects run late. This is expected behavior for software development. Though we’d like to think we had our whole solution mapped out from the start, we’ve discovered a lot of things we needed to have, eliminated a lot of frills, experimented with different technical approaches, and, yes, wasted time.
That’s the nature of creative work. Software development is not really an engineering discipline, though we’d like it to be. It’s more like writing the great American novel. Some mornings you can write a whole chapter before your first cup of coffee. Other mornings you struggle to find the right word to begin the first sentence. Still other mornings you spend crossing out all the bad ideas from last night.
All in all, we’re pleased with our progress so far, but we’re going to need a longer runway than we thought before we can take off. That’s OK; for now, we’ve got the cash and our expenses are low. Our biggest worry is that we might miss the window of opportunity for enterprise social software. Or that someone else might beat us to the finish line. It’s a healthy concern. It keeps us motivated.
So we’ll keep scrambling to get our ideas into code form. In the meantime, we’ll keep you posted on our progress. And you can help us out by telling us what you’d like to see in enterprise social software.