I know I don’t talk about work or work-related subjects very frequently, but considering how much of my time it takes up,
I’ve started to wonder why not. I mean, it can’t be all because of NDA’s and trade secrets and the like. After all,
let’s face it, nothing I’ve done in the last 5 years has been highly cutting edge or completely unique. Perhaps I’ll
discuss why that’s not depressing to me later. In any case, I have some thoughts to share on lots of different subjects:
why things matter and/or why they don’t matter, mostly.
To kick things off, I’ll refer to a conversation which was going around the other day. We were discussing the design of
a feature and one of my team members, in order to identify why we can’t do something, stated that this is a “date-based
feature”, and the statement made it clear that this was a Very Bad Thing. This piqued my curiosity: what is inherently
bad about a date-based feature?
If you don’t know, a feature typically has two main permutations: date-based and design-based. A design-based feature
would be one which ships after the design has been agreed upon, all the development of the feature is addressed and
executed, and any iterations which come up are addressed. The philosophy here is that, if there is an unseen change or
obstacle in the development of the feature, whether in the design or in the technology, the date on which we ship the
feature will slip. Conversely, for a date-based feature, scoping and planning the feature happens, and the team commits
to the date; if the same unseen change or obstacle comes up, sacrifices must be made because we still have to ship on
the same date.
A short deviation. For the sake of brevity, I’m going to boil down every feature into two development disciplines:
design of the feature (what is the feature going to do), and technology (how is it going to do it). In the real world,
there are more components than just this, but these two disciplines will still be the bulk of all major decisions in the
development process.
The complaint which my teammate raised was that, since we’re working with a date-based feature, it inherently wouldn’t
be as good as a design-based feature. And sure, there is validity to that. If we commit to shipping on a specific date,
unless that date has already incorporated major iteration time, it doesn’t allow for surmounting major obstacles. What
happens if we change the design of the feature in some meaningful way? What happens if it’s not possible to use the tech
stack how we’d anticipated doing? We now have to address these issues as well as all the remaining and pertinent original
work. Sometimes, and this is rare in my experience, this will cause a reduction of scope, which doesn’t cause a problem.
Almost always, this means we now have more scope. More scope equals more work to complete in the same amount of time.
This will cause employees working more hours, will cause the trimming of various pieces of the feature in order to
reduce scope sufficiently (a.k.a. cutting corners), or both.
By contrast, a design-based feature waits for the feature to be complete and “perfect” before releasing it. If there are
any roadblocks along the way, they’re addressed as they come up. Major roadblocks can end up delaying the release of the
feature for a very long time, but you can be assured that the feature is the best you can get, technically and in
design. Therefore, you don’t have to worry about cutting parts of the feature, working large amounts of hours to make up
for increased scope, etc.
What is the value of releasing?
If you release the wrong feature, it will be unsuccessful. This can be looked at in a couple ways. For instance, what
happens if you have a good idea implemented poorly? This is more likely to happen in the case of a date-based release
system. You’ve had to leave a couple things off which, while they’re not essential to the functionality of the feature,
they certainly make the feature more user friendly.