I always wanted to master product development. It's what drove me to become a full-stack web developer, and then expand into UX methods and UI design through a lot of self-guided education.
For a long period of time, I worked on creating a solid foot-hold in web technologies; there's a lot of multi-disciplinary complexity inherent in web apps.
I think one of the reasons this endeavor was ultimately successful was my long-term, persistent focus on a few pet projects. I'm talking decade-long focus here. So I wasn't just learning the tech — I was ever evaluating how whatever I was learning at the time could help me in building these projects.
I was also grappling with how to approach the development of a brand new web application methodologically. What comes first: the UI, Ryan Singer-style? The database design? Should I create a "mock" system with a data structure playing the part of the database, and focus on getting the business logic "right" initially?
At some point, it struck me that what I was trying to do could be reduced to:
- Transmission of messages (as client-server data exchange)
- Encoding of data or signals (through formats such form data, HTTP URL strings, JSON and CGI)
- Knowledge representation (real-life business objects modeled by our systems).
The work of a web developer, it seems, is fundamentally rooted in information theory. What we really are doing, even when coding a simple web app, is information system design based on transmission of data.
This was no random insight. I had been reading voraciously across multiple disciplines. The Tracer Bullet Development (TBD) method described by Andy Hunt proved to be instrumental.
The topic of complexity, and how it arises in software systems was a key influence as well — covered in Rich Hickeys radically enlightening talks and the amazing Out of the Tar Pit.
Then one day (it was one of those days when you feel Unverse is conspiring against you), I sat down with a pen and a piece of paper, and drew out a diagram of what I was doing. Straight away, it looked like a method.
The drawing encapsulated the thought that to do product development systematically, one must consider these elements concurrently:
- Business analysis
- Information architecture
I looked like I was on to something. I followed the trail, and kept digging deeper. I looked at the intersection of data analysis, functional programming, and informaion science — and gained amazing insights. Over the next few months, I fleshed it out the theory behind the method.
Here's a one-sentence summary of it:
A web application is a device for amplifying the value of data, gathered over time.
This perspective helps me every time I need to consider an new application — especially its first iteration.
I called it Protosprint (a "prototype sprint").
The initial feedback is very promising. I'm looking forward to sharing it with you.
Edited September 2022.