Archive for the ‘Development’ Category
One to Throw Away
Eric Raymond wrote about the release early, release often mantra heard often in the Linux open source community in his famous software essay The Cathedral and the Bazaar. Since then, it’s become the rallying cry of the extreme programming and agile software communities, and driving principle behind Web 2.0 companies everywhere.
Paul Graham listed “release early” as the #1 Hardest Lesson for Startups to Learn. So we were determined not to make that mistake when we started Infovark.
Oops
It’s taken us two years to release version 1.0 of Infovark. Sure, we had some Alpha and Beta tests along the way. We also had several prototype and demo versions. These don’t count as a release, though.
If you summed up our development experience over the past two years, it didn’t follow the trendy “release early, release often” paradigm as the much older “build one to throw away” model. Build one to throw away is a famous line from Fred Brooks’ seminal work, The Mythical Man-Month.
Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.
Tim Bray describes exactly that experience when working on a module to implement the Atom Publishing Protocol. And you could argue that Microsoft’s recent experience with Windows Vista and Windows 7 follows that model as well.
It certainly describes what we did with the Infovark Alpha. We restructured and rebuilt almost the entire application based on what we’d learned. The idea remained the same, the look and feel stayed roughly the same, but everything under the hood got a total rewrite.
It easily added nine months to our release schedule.
The right choice
It was a really hard decision to make, but it was the right one. We have a much faster, much more stable system to work with now. The number of bugs we’ve had reported to us in the two weeks since release is lower than any other 1.0 version of software I’ve worked on.
I’ll talk about the gory technical details of what we did and why on our Underground blog, for those that are interested.
You can download a trial copy of Infovark here. And for those of you that have it already, you might want to check out our very first update announcement.
Because from here on we plan to release early and often.
Startup Schizophrenia
Unless you’re one of the lucky winners of the venture capital lottery, or happen to be independently wealthy, starting a new business is a difficult proposition.
It’s especially tricky for companies in the product business, because so many of their costs are front-loaded — they incur the charges long before they can recoup the money from customers.
Infovark is lucky, because as startup companies go, software companies are cheap to run. Computer software and hardware are relatively inexpensive these days, and you can work anywhere that there’s a decent Internet connection and few interruptions.
Assuming you don’t count the cost of labor, of course.
That’s the reason so many software start-ups are located near universities with good computer science programs. The biggest asset a software company can have is an endless supply of folks that will write code for pizza and beer.
Gordon and I can’t work for free, though. We’ve got mortgages and families and responsibilities and stuff. Which contributes to a problem I call startup schizophrenia.
Supporting our coding habit
We started Infovark with money raised from friends and family, but no matter how frugal we are that money won’t last forever. So, starting six months ago, Gordon and I started doing occasional side projects.
On one hand, it’s been a great thing for us, because it’s helped us preserve our cash during the downturn. It’s also kept us connected to the Enterprise Software community, the Enterprise Content Management space, and the larger arena I’ll call “corporate computing”.
We know that space well, and we know that organizations need the help of experienced consultants to keep their disparate software systems working together.
But that space, familiar as it it to us, is not really Infovark’s market. And while we firmly believe that something like Infovark would be useful to a lot of people in the business world, it’s not something that CIOs or IT directors would find very interesting. The folks that manage back-office corporate infrastructure have different concerns from those that work directly with customers or are out in the field.
So Gordon and I find ourselves switching mental models a lot.
Wearing our consulting hats, we’ll talk with companies about security, scalability, interoperability and then we’ll hold an Infovark conference call where we’ll talk about sharing, openness, and ease-of-use. It’s a different set of priorities, driven by different motivations.
It’s a strange disconnect. The cognitive dissonance gets to us sometimes.
Shifting gears
While we were preparing for the beta release, we spent a lot of time dwelling on the subject of enterprise software. It’s what we know best. It pays the bills. And we’ll be more than happy to help folks with their ECM deployments or change management initiatives.
But over the coming months, I think we’ll talk less and less about corporate computing and more and more about personal productivity.
Our focus is changing now that the beta has been released. We can now get feedback from actual users that have tried Infovark. We’re hearing a lot about what features work and what things confuse people.
The folks at 37signals call it Getting Real. We had a theory about a personal information sharing application that was easy to install and use. Now we have to put it into practice. We’ll learn a lot about which of our crazy ideas work and which are just plain silly.
And as we do that, this blog will be less and less about the places we’ve been and more about the places we’re going.
In the meantime, enjoy our mental disorder.
Lipstick on an Aardvark
After our first round of product testing, we decided to make big changes in the look of our Infovark product. This is the first of an occasional series of posts about the design of the Infovark Beta.
We use the Infovark mascot — we call him “the Vark” — to represent our company. We use his head for our avatar in twitter and as the favorite icon for web bookmarks.
I like the simplicity and abstract look of the icon. It has a certain Scott McCloud less-is-more aesthetic to it. As Scott explained in his book Understanding Comics, the less detailed an illustration is, the more it invites the viewer to use their imagination to fill in the gaps. The more detailed a drawing, the more it represents a particular thing. We wanted Infovark to be about you, the knowledge worker, and not about us, Gordon and Dean, two guys making software.
We also chose an animal mascot for a reason. The Infovark name was partly an accident, but it stuck because it was a useful metaphor for us. Infovark does a lot of work in the background for you. It watches files, catalogs email, indexes content, and other useful things automatically. We liked the image of an animal digging through your information, trying to find interesting items and making associations between files, contacts, and email. It made our software feel friendly and helpful, like an enthusiastic pet you’ve taught to do neat tricks.
For round two of our product design, we wanted to try giving the Infovark just a little more personality. But not too much personality. Ever since Microsoft introduced Clippy to the world — and to much popular scorn — software developers are mindful about overeager assistants. Does anyone remember these guys? It’s a fine line that we’re walking here…
So after much consultation, this is our attempt at something a little cuter, with a touch more detail.
What do you think? We’ll use this new character on our redesigned blog theme, and possibly in the product itself. Leave a comment and let us know your thoughts!
Ideas and Forms
Here’s a philosophical topic to start the week. Information Aesthetics, a blog about design and data visualization, posted two videos from Maya Design. The first discusses the term information, the second architecture. As a software developer, these are terms I use all the time, but I often have a hard time defining precisely what they mean.
It’s a bit of a challenge for our marketing and communications strategy. The core API for Infovark, our product, is fundamentally nothing more than an information architecture. We use this core to create solutions that help knowledge workers get stuff done. But if information and architecture are tricky to define, you can imagine the confusion involved in combining the two! But where was I?
The two videos do a great job describing the terms information and architecture from the classical point of view.
- Information is the essential message being communicated. It is separate from the form the communication takes.
- A design is a plan for making a thing. An architecture is a design for making plans.
These definitions are classical in the sense that they rely on Plato’s concept of an idea being separate from a particular physical representation. There are other approaches. For example, Marshall McLuhan believed that “the medium is the message” — that you can’t separate the meaning from the representation that conveys it.
Did I mention this was going to be a philosophical post? I did warn you…
Getting real
Even though the topic is a bit academic, there are real-world debates going on about representations and forms right now.
How many differrent representations of you can be found on the web? There’s your LinkedIn profile, your Facebook page, your StackOverflow account…
Much of the buzz surrounding the open stack technologies is due to there being a way to finally associate a person with all the stuff about that person on the web. Wikipedians talk about having “canonical URIs” — a web page address that points to the master record for an article, rather than a particular translation of an article. And if you support or build software that uses the REST pattern, you’ll face this issue. What is the base address for this web page? How do I get to the HTML version, the XML version, the PDF version, or the MP3 audio version of the page?
There’s not a “right” answer to any of these questions, but we usually adopt certain conventions for dealing with them. Libraries had to figure out whether to keep Braille editions of books together with the print editions, for example. After all, they’re the same book — they contain the same message — but the format is different.
We’re working out those same conventions on the Internet right now with regard to privacy, data portability, text translations, podcasts vs. screencasts vs. print, etc.
