I am now just over a week into the development of an experimental new project. The project is, on the surface, to build a new type of Wiki. But really, the project is about the development process itself and a new way of thinking about software development. In fact, because of that new way of thinking, I've even come to a better understanding of what this project could mean.
Stephen O'Grady first labeled the project for what it is -- an exercise in transparent design. While I wouldn't have initially thought to call it that myself, Stephen is exactly correct. Every step and misstep along the way is being publicly documented in the hopes that a greater return can be found through a transparent development process. That greater return is taking many forms:
- Increased publicity
- The organic growth of a community
- An evolving feature set based on early feedback
- Better design due to being forced to look at the hard parts early
- Better design due to outside feedback
- Increased motivation
- Sharing of knowledge
- Easy, accurate, and honest documentation
I had been kicking the idea for this project around for six months but never really did much with it. But once I started posting about it once a day, the pieces just started falling into place. Finding the time to work on the project is hard, but somehow this transparent development process has found a way to overcome even a busy schedule. Perhaps actual coding could have progressed further in one week without all of the superfluous (and I admit, rather wordy) writing, but I don't believe the project would be even a fraction of as far along the path toward a workable design.
I am curious if this type of process could work internally at a software company... Should developers write their own development blogs? Should they publish their exercises? Some companies require design reviews -- some even on a regular basis. But that is different than on an ongoing basis. By making public the developer's thoughts, even before they are fully formed, you have the opportunity to influence change at the earliest -- and least costly -- moment. This is clearly a technique that falls squarely in line with Agile processes, and it is something that I will want to experiement with further.
Taking stock of the progress so far, I feel I am getting a pretty good handle on the high-level architecture (i.e., a web service, multiple clients, etc.), and some real world usage scenarios (personal note taking, sharing, lightweight CMS). Some technical details have been addressed (REST, Ajax, etc), and critical parts, such as the web services API, are beginning to look pretty robust. Peer feedback via comments on the site have been invaluable in shaping the direction of the project. Quite simply, the design is much better thanks to the readers than it would be if I had attempted it in isolation.
I hope to begin coding sometime over the next week. There are still a few hurdles, including:
- Hosting
- Source control
- Choosing a programming language
- Naming the project
Each of those concerns need to be addressed before any code is written, so I will be working on each issue over the next few days.
And in the spirit of transparency, I will share an insight about what I think this project really means. For one, it's not just an experiment. It is both the start of a real-world application and the beginnings of a community.
But more than that -- it isn't just a new Wiki. The transparent development process has helped me see that the web services API that powers one application -- a simple wiki -- is really the foundation for something much more interesting. Because at the end of the day the web services API, with its users and groups and invitations and relationships, etc., is a necessary bit of functionality for hundreds of interesting social applications. And there is absolutely nothing in this design that would prevent any number of new projects from leveraging this work, either as a design, as code, or as an actual web service.
So while this first version will augment the API with features necessary to support wiki-like notes, anyone else could write their own web services -- perhaps even hosted on a different machine and built entirely independently -- that would do just about anything. And people may actually feel comfortable using this project as a starting point for their own work, as every decision along the way is open to the public for review. The motivations and goals are laid bare along with the design and the code itself. I don't doubt that I would trust other companies more if they did a better job at transparent development -- not just coming up with clever marketing slogans about how good they are.
Of course, that's all still a long way away. I am still very likely to stumble and fall along the parth to that goal. But at the very least, if anyone liked the idea they could just pick up where I left off.