5 ms·

Everywhere I've worked has been in reactive mode. We never have time to slow down and adjust. Never given any time to work on the infrastructure projects that w

by ctrl-j 10y ago

Everywhere I've worked has been in reactive mode. We never have time to slow down and adjust. Never given any time to work on the infrastructure projects that will give us the tools to do our jobs better in the long run. This looks like the epitome of reactionary development. Plus it doesn't lend you any real insight into the "why" of a given problem. In the included example, latency is up on a given method. Lets say it turns out that particular process calls three different "manager" classes, and has another inline sql query. So, you do the right thing and spend a bunch of time cleaning it up and getting things looking more right (with no help from MDD, since there's nothing about development practices in this outline.) Turns out, it wasn't the code after all. Someone had designed autocomplete to work off of a sql table, and someone else disabled the job that re-indexed the search column. * Long story short, TDD and BDD give us development tools * MDD appears to give us... help making minor decisions on potential focus areas? Maybe ammunition to tell our PMs what we should work on? Anyone else see what the big draw for this would be?

pionar 10y ago
>Everywhere I've worked has been in reactive mode. We never have time to slow down and adjust. Never given any time to work on the infrastructure projects that will give us the tools to do our jobs better in the long run. >This looks like the epitome of reactionary development. Plus it doesn't lend you any real insight into the "why" of a given problem. How do you know those infrastructure projects are the right projects to do? Will those bring better business value than something else (bug fixes, etc.)? Noting that developer happiness is a measure of value, maybe they are. The only way to really know is to measure it. Put telemetry in there that tells you how your current infrastructure is affecting your business. Does the poor infrastructure lead to more bugs, costing the business more in developer time that could be spent on new feature development? Does the poor infrastructure drive down customer retention or new customer acquisitions? I think the author's point is that if you don't know what people actually do with the code you write, you can't prove that making changes will provide business value. Being proactive instead of reactive is very difficult if your product managers don't know what your customers find useful. They can't know what your customers actually use your product for without metrics.
- marcosdumay 10y ago
  How do you know those bug fixes, small features, etc are the right projects to do? You simply don't, and are circling "instrumentation" and "measurements" in hope they tell you anything useful. But all measurement in the world won't help you know the value of something that does not exist yet. Instead, you take a risk. Every time you are deciding what to create, you are taking a risk. People that keep claiming for those reactive methods just don't like big risks. No problem with that, but they also won't see any big rewards.
  - slgeorge 10y ago
    >You simply don't, and are circling "instrumentation" and "measurements" in hope > they tell you anything useful. But all measurement in the world won't help you > know the value of something that does not exist yet. Instrumentation and measurements help to create an argument in support of doing X. Imagine the conversation .... Dev Manager enters the VP's office, "Hi Bob, dev team X cost roughly 1 million USD a year, they'd like to work on an infrastructure project, current estimate is 4 months but you know how it goes, it'll be six by the time it's done. ", Bob replies, "OK, so 500k of cost, what business value will it deliver?" "I dunno. Well they actually say that you just take a risk, cos every time you make a decision you're taking a risk - and without big risks there are no big rewards". "Yeah, I'm not taking a big risk with my familys future by being fired for not having any sort of defensible thesis as to why we decided to work on this project versus any of the others that other departments are screaming for. So thanks but no thanks." "Oh no, but you don't understand, they're extra special. Team X are superstars they can't possibly measure their contribution like other business functions are expected to. Cos you know it's tech - it's like magic and if you don't get it you're just not smart enough". "Yeah, they might be smart, but they're not smart at making arguments that will help me fund this project. Come back when you've got a good argument that I can defend to the CEO with a straight face" ... and that's the problem, big risks sound great when you're not on the hook if it doesn't come good. Ofc if you live in Google (or similar outlier) then you probably don't care because money is showering in from the heavens. But most businesses are in reactive mode because they're trying to steer between the various rocks of problems they face!
dragonwriter 10y ago
> MDD appears to give us... help making minor decisions on potential focus areas? Maybe ammunition to tell our PMs what we should work on? As described here, it seems largely a way to monitor for and address operational issues before they become "hair on fire" crises, though with the right metrics it could also be a way of focusing development strategic priorities around the business value more effectively. OTOH, what both this article and the linked, more-detailed overview of MDD leave out -- and which is critical to either of these uses -- is any deep discussion on criteria for identifying the right metrics aside from "devs know best" (I also think that the focus on developers identifying metrics is probably wrong unless the definition of "developers" is at least broad enough that it includes DevOps.) There's some beginnings of ideas that may have utility here, but there's not really a clear coherent well-developed methodology, the way the name "Metrics Driven Development" suggests.
jhoechtl 10y ago
Working according to this model will make you really unhappy and bring you to burn out. It seems it's made from and for the CEO/CFO level but not to build up a friendly ecosystem.

by ctrl-j 10y ago

pionar 10y ago

>Everywhere I've worked has been in reactive mode. We never have time to slow down and adjust. Never given any time to work on the infrastructure projects that will give us the tools to do our jobs better in the long run. >This looks like the epitome of reactionary development. Plus it doesn't lend you any real insight into the "why" of a given problem. How do you know those infrastructure projects are the right projects to do? Will those bring better business value than something else (bug fixes, etc.)? Noting that developer happiness is a measure of value, maybe they are. The only way to really know is to measure it. Put telemetry in there that tells you how your current infrastructure is affecting your business. Does the poor infrastructure lead to more bugs, costing the business more in developer time that could be spent on new feature development? Does the poor infrastructure drive down customer retention or new customer acquisitions? I think the author's point is that if you don't know what people actually do with the code you write, you can't prove that making changes will provide business value. Being proactive instead of reactive is very difficult if your product managers don't know what your customers find useful. They can't know what your customers actually use your product for without metrics.

marcosdumay 10y ago
How do you know those bug fixes, small features, etc are the right projects to do? You simply don't, and are circling "instrumentation" and "measurements" in hope they tell you anything useful. But all measurement in the world won't help you know the value of something that does not exist yet. Instead, you take a risk. Every time you are deciding what to create, you are taking a risk. People that keep claiming for those reactive methods just don't like big risks. No problem with that, but they also won't see any big rewards.
- slgeorge 10y ago
  >You simply don't, and are circling "instrumentation" and "measurements" in hope > they tell you anything useful. But all measurement in the world won't help you > know the value of something that does not exist yet. Instrumentation and measurements help to create an argument in support of doing X. Imagine the conversation .... Dev Manager enters the VP's office, "Hi Bob, dev team X cost roughly 1 million USD a year, they'd like to work on an infrastructure project, current estimate is 4 months but you know how it goes, it'll be six by the time it's done. ", Bob replies, "OK, so 500k of cost, what business value will it deliver?" "I dunno. Well they actually say that you just take a risk, cos every time you make a decision you're taking a risk - and without big risks there are no big rewards". "Yeah, I'm not taking a big risk with my familys future by being fired for not having any sort of defensible thesis as to why we decided to work on this project versus any of the others that other departments are screaming for. So thanks but no thanks." "Oh no, but you don't understand, they're extra special. Team X are superstars they can't possibly measure their contribution like other business functions are expected to. Cos you know it's tech - it's like magic and if you don't get it you're just not smart enough". "Yeah, they might be smart, but they're not smart at making arguments that will help me fund this project. Come back when you've got a good argument that I can defend to the CEO with a straight face" ... and that's the problem, big risks sound great when you're not on the hook if it doesn't come good. Ofc if you live in Google (or similar outlier) then you probably don't care because money is showering in from the heavens. But most businesses are in reactive mode because they're trying to steer between the various rocks of problems they face!

dragonwriter 10y ago

> MDD appears to give us... help making minor decisions on potential focus areas? Maybe ammunition to tell our PMs what we should work on? As described here, it seems largely a way to monitor for and address operational issues before they become "hair on fire" crises, though with the right metrics it could also be a way of focusing development strategic priorities around the business value more effectively. OTOH, what both this article and the linked, more-detailed overview of MDD leave out -- and which is critical to either of these uses -- is any deep discussion on criteria for identifying the right metrics aside from "devs know best" (I also think that the focus on developers identifying metrics is probably wrong unless the definition of "developers" is at least broad enough that it includes DevOps.) There's some beginnings of ideas that may have utility here, but there's not really a clear coherent well-developed methodology, the way the name "Metrics Driven Development" suggests.

jhoechtl 10y ago

Working according to this model will make you really unhappy and bring you to burn out. It seems it's made from and for the CEO/CFO level but not to build up a friendly ecosystem.