Do the simplest responsible thing that works.
That is, responsible to highly probable future features; responsible to your known performance demands; responsible to your business's security and reliability requirements.
Above all, responsible to your future teammates (and your Future Self) who will have to support and maintain that code. Happily, this last responsibility is nicely supported by the emphasis on "simplest."
Note also that it is "simplest," not "easiest." Your old familiar habits will be easiest, but if those habits were formed in a different paradigm—say... old ASP that you learned by osmosis (Hey, we all had to start somewhere.)—then it will take some dedicated study to turn the responsible thing, the simplest thing, into something you can do easily. Meanwhile, the state of the art in Simple will keep moving, but that just gives us something to keep striving towards. That's what keeps it interesting, right?
6 comments:
Isn't being "responsible to highly probable future features" in conflict with YAGNI?
Don't build for "stuff we might need next year," but do build for "stuff we're going to build next month." I think if you rationally apply "simple" and "responsible," you'll avoid YAGNI frameworks.
I'm still learning to apply the principles and "apply xxx principle rationally" does not tell me much. I'm looking to understand the trade-offs between principles and know when/how to apply them.
I'm all for building a system that's open for extension. However, spending time and resources on a feature deemed probable by developers not by business does not sound right. How do we know we're adding value?
Sure, I can expand on these topics.
First, I would hope it was not the developers deciding a future feature was probable, but instead that the business people are sharing their product backlog with you. That they are maintaining a prioritized (ordered) list of features, in a place where you can see it, too. Features down the list in position 9 or 10 are pretty unknown, but #2 or 3 is rather likely to get selected for an upcoming sprint.
You're weighing a trade-off between "likely to happen" and "expensive to build accommodations for." If a feature is far down the list (far in the future, and therefore not very likely) and it would push you to build a lot of infrastructure without obvious business benefit, that is probably a YAGNI ("Ya ain't gonna need it," for the benefit of other readers) case. But if you'll probably start Feature B next week, and it is rather simple to build Feature A with an eye towards Feature B, then I would say it is safe to keep Feature B in the back of your mind while building Feature A.
Second, I cannot give you a perfect formula for making these decisions, and you shouldn't trust anyone who says he can. You have software experience, Alper, you're a developer, you think rationally about problems, so trust in that. You'll use your best judgement, make some mistakes, and then learn from those mistakes.
I know, I know, don't roll your eyes. But that's how to learn this stuff, right? Using the knowledge and experience you have, you make the most responsible decision you can, and that gives you more experience to inform the next decision.
"make some mistakes, and then learn from those mistakes"
One thing I wonder is why we can't collectively, learn from other peoples mistakes. If we all have to make the same mistakes before we get to the next level aren't we headed in a cyclical direction with the next wave of developers. How come people don't actively blog about mistakes they have made/are currently making? It would be nice to see some logic as far as how they got in the predicament they are in and how they managed to wiggle out of it.
>How come people don't actively blog about mistakes they have made/are currently making?
Because their employers would consider it actionable? ;-)
I try to, but it's delicate to figure out how to talk about an issue without revealing company secrets or hurting a teammate who might see himself in what you wrote.
Your point about learning from each other is a good one. It's why I'm enthusiastic about developer conferences, especially the more free-flow ones like Open Spaces or Code Camp. I like those because they support peers talking to peers, helping each other with real, current issues. (Instead of structured, vendor-sponsored demos and the like.) And they can be very grass-roots; just gather together fellow professionals and give them a starting topic to talk about. :)
Post a Comment