For a given project, you’ve likely heard that whole spiel about you have:
- Time
- Budget
- Performance
Then you tell a person to pick two. In my experience, this tends to be true, especially when working with tight constraints or smaller budgets. And that’s okay! It’s not a complaint and that doesn’t mean we can’t still do a job well done given said constraints.
But this post is not about that (although it might be fun to discuss). Instead, it’s about a follow-up question that I’ll occasionally get around this same topic:
Once you’ve landed the project, what is development? How do you know how to solve problems for different people?
And I think, at first, it’s an interesting question. I mean, if we all went into a project not knowing what we were doing – regardless of the industry – then that’s a little scary.
In programming it’s its own beast, isn’t it?
Anyone remember The Neverending Story?
I mean, we know what the client wants and we know we can build it, but how do we express that we don’t necessarily yet know the code we’re going to write or how we’re going to write it?
