Where to start? There are two places the user interacts with this system.
* When the original url is shortened
* When the shortened url is followed
Which makes more sense to start with?
Shortening a url
If we start with shortening the url we could have a demo that shows whatever the user interaction is, for this example we can just do a POST like so:curl --data "url=https://i.ytimg.com/vi/oM1EVAYahFE/maxresdefault.jpg" localhost/shorten
That would return some sort of success or failure with a shorter url on success.
If we go this path the first slice will be to return a url that won't work for the success case.... and to return an error for failure cases. Given what we know now I'm not quite sure what the failure cases might be, and it's hard to think of a demo between it returned a 200 and a url and the full shorten -> fetch pipeline works. We could demo putting the data in a database, but without knowing the fetching side it's hard to know exactly how we want to organize that.
Let's see if the other starting point is more obvious.
Following a shortened url
A nice starting demo is what happens when we try and follow an invalid short url. So say curl localhost/s/totally_a_fake_key. That demo is nice because that's a use case that isn't likely to change too much as we discover more about the system.
We could follow it up with demos of redirecting shortened urls based on a hardcoded hash.
That sounds like an easier place to start and also builds out the most common customer interaction point first, which allows the UX or product team to have something meaningful to demo faster. It also means that by the time we get to data storage we'll have a good idea what data we need to read and what operations need to be fast.
Okay, lets build it.
<TODO> finish me!
Old post:
Driving from Consumption is simple and logical in theory: start with what the user interacts with and work backwards from there.
Sure, let me just understand the entire problem space and then we can do the DB design and we'll do the UI before the api. Weird, but I can try that.
Nope.
Actually just focus on the next thing. Just build the UI. No actual api calls. Just hardcoded JSON data. Is that the right UI? Do customers like it? Is it what product wanted? Does product actually want us to stop here because we came up with different ways of doing it and they want to do usability tests?
Okay, now the API. Just the API. No db calls. The data can be hardcoded inside the tests. Oh, you want to back it with a model? Okay, after the hardcoded version works then there can be a model with hardcoded data in its tests. Then, eventually, finally it can pull from the database. Though there isn't any data there. At least not outside of the integration tests. Now we can put the data in!
You've probably been screaming this whole time. But wait! How do you know what the model should look like without considering the database? You're going to code yourself into a corner!
Sometimes. Usually not though. In fact I haven't run into a dead end yet. Instead the later changes are usually small, simple and obvious.
It's really scary to let go of planning out the entire code arch ahead of time. So much of what we pride ourselves on as developers is being able to foresee dead ends and avoiding refactors. Unfortunately all that effort takes time, cognitive load, and requires a certain level of familiarity with the code and the problem space that everyone on your team may not have. That means they're suddenly in the middle of someone else's idea without understanding where it came from.
If instead of that upfront cost and accidental over designing you accept under designing and small refactors as they become necessary it isn't actually more overall work. And suddenly everyone can participate in the design because everything is concrete.
Will it work for you? There's only one way to find out.
Related topics:
