My dev team is prepping the release of our REST / RSS / JavaScript based account management this week. It marks the completion of building, then harnessing, a suite of RESTful RSS 2.0 feed based web services. The idea has been “avoid people wasting time, working on stuff they suck at focus developers on code they enjoy and excel at.”
We had problems with our 1.0 account management. User interfaces were tied too tightly to the back end. Heavy hitting framework and server programmers were working out UI kinks while artistic graphic designers were figuring out database calls. This was a huge waste. The site looked heinous and didn’t work the way we wanted it to.
Graphic designers don’t think in OO, let alone big-O. Server programmers don’t communicate visually.
It seems easy to fix, right? Just have heavy hitters do hard stuff and then have graphic designers make it look pretty? Make it look pretty first, then tie in the hard stuff? Not exactly. It requires a lot of planning and effort to coordinate and manage people’s time like that. It also requires serial development where people are waiting before they can start. All of which is a waste – this needs to be automatic and parallel. Don’t waste time trying to manage this if it can be done for you.
Enter REST. Enter RSS.
RSS (Really Simple Syndication) came first. Dave Winer, back in ’98, grew it from XML. It allows for simplified packaging of data. One can package and list blog entries, offer an MP3 playlist, send table-of-contents information, or transport code via codecast. At iofy we use it as a container to package web service responses.
RESTful development is also based on simplicity (here’s a great doc on REST). Get things done in an HTTP packaged call. With a very simple request in JavaScript, the web service is queried and you’ve got an RSS feed as a response. Our designers have their functionality via web services. Our server coders don’t touch the front end.
The server developers make the RSS feeds. This makes them happy and gives them time to build the critical server components. The graphic designers use JavaScript to call iofy’s RESTful Web Services API (link coming Monday). We use jQuery as our base JavaScript library. It’s damned fast to dev.
This simplified my project management. Tasks became clearly defined. In the beginning I was worried the approach would put a wedge between roles, but it worked in reverse. People understood the importance of their own functions and became reliant on each other for success.
Parallel Development.
While the design team determined a desired look and feel, the back end team planned architecture and database schema. As feeds were developed and APIs took shape, so did the layout of the site. When feeds became ready for harnessing, pages were ready. Management of the nitty-gritty became unnecessary.
We launch account management this week. You too can harness it in your language of choice (we’ll provide JavaScript code which lets you do this simply by dropping some .js on your page and a script on your server). iofy’s services are controllable from your own site.
iofy’s development team builds client software, web sites, and web services powering audiobook content delivery. We move content securely from server, to client, to iPod, and SD chip.
I’m reading