Forging a microsite from zero is no small task. Even with focused goals, we expect our engineers' keyboards to tremble under their constant typing.
On the surface, back-end code is $('mumbo').jumbo. But when we approach it with goals, the process becomes clear. The site needs to let users buy tickets for upcoming events. That's its job.
By 2:30pm Matt and his team had completed a data model. Based on user processes fresh off the whiteboard, the model is a map to creating the underlying Postgres database. The database holds the content. Content frames the design. Design informs the code. And off we go.
Actually, our engineers are building two systems. There’s a microsite and a web-based tool to manage the microsite. The content management system — also built from scratch — allows people at Rebuilding Together Peninsula to create and schedule future events.
Future? You bet. This isn't a one-off web project. The back-end is written so our non-profit partners can use it for future events, or even future microsites.
Testing Code with Code
Our engineers know that at 8am tomorrow — less than 16 hours away — they’ll hand their code over to our non-profit partners … and that’s it. Once it’s live, it’s live.
In the past we’ve tested websites as you might expect: by trying them ourselves. If a website works, great. But we also try to make them not work. We leave required information out of a form to make sure error messages work. We try layouts on many different devices. We try to imagine everything that can go wrong.
But “everything” is a big word. When we have weeks to test everything, we do. But now we have less than 16 hours. So our engineers decided to use a technique called Test-Driven Development. In non-geek speak, they write code that tests code.
And while they write code, test code, code databases, test the code that writes to databases, the rest of the team continues to develop content, flesh out designs, and prepare front-end code that will all come together very soon. Where did the day go?
