Signs you’re working in a feature factory (2016)

The methodology of recent history has been to instrument everything, and then use that to analyze. I'm not ignorant, I've done this. It's an effective way of not fooling yourself. However, the downsides of such data collection have, for the most part, been ignored in the process of determining what to instrument, how that data is stored, and what is to be done with it. This is an industry-scale oversight and is going to rapidly change, especially in light of new regulations.

Beyond the fact that such data is a liability (and usually can be de-anonymized) and the legal requirements of having it being burdensome, organizations need to ask the question of if their data collection policy is ethical. Your "universal recognition" in my mind is more of a "universal blind spot". On the contrary, instead of saying that lack of a data collection policy is a cop-out due to laziness or lack of care, I'd argue that falling back on collecting data shows a similar kind of laziness, where you've failed to come up with a better solution to your problem of understanding how well your product is performing that doesn't require violating the privacy of your customers. (Even if you aren't violating it per se, you're only one data breach away from someone else doing so, and that would be entirely your fault.)

The correct methodology is to try to solve these problems with minimal data collection, ideally none. It also means sometimes you will not collect data, and knowingly potentially miss insights, because the trade-off doesn't make sense.

That doesn't mean you don't do it, but it does mean that when you do, you should recognize it as a liability, a deep trade-off that has many negatives, where the benefits should outweigh it. If it's not actionable, don't collect it. If you don't need it anymore, permanently delete it.

Most organizations don't see it that way, but I predict many will in the coming years.

It's simply saying that you measure before you build a feature [and again after]. Any good product owner will already have data to support their prioritizations (e.g. this bug affects 10% of users, this feature only applies to 2% of users)

I don’t think this is a good solution. It is certainly “A” solution, and one that many folks pick.

Software Development is ALL about creativity. It’s really hard to make computers work; the best developers make them sing. Time and again I’ve seen fairly mundane teams hire an engineer with the energy and drive to push the boundaries of what’s possible and end up doing great work. I do think that developers can be agents of change this way; it’s not easy but it’s possible. And it can be very fulfilling and inspiring to be both someone who benefits from great work and to be a person that does great work.

I do agree that life may decide your priorities for you at times. Kids, spouses, relationships are all very important and compete for time and at some point you have to decide if it’s worth it to put in extra to do great work. It doesn’t mean though that Software Engineering is devoid of creativity. It’s been pointed out that software engineers can be one of the most productive assets of a company, and that productivity isn’t achieved by magic but by creative problem solving.