3 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

by 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!
  - ctrl-j 10y ago
    If you argue major decisions that way, you're going to get shut down every time. I'm not arguing against measurement or thoughtful decision making. I'm saying it's not a good way to engineer a product. What would you do if Ford practiced this when designing a new car? "Hrm.. metrics show that gas vapors leaking into the cabin lowers sales... I guess in the next version we shouldn't put the gas tank inside the cabin. The previous metrics said it would save money by reducing overall material costs!"
  - neeleshs 10y ago
    Im having a hard time to imagine this conversation. Infrastructure projects typically need a lot of buy-in from across teams (due to costs) and are geared to solve specific problems the business faces. This has been my experience in small/medium sized companies which had to juggle among fixing bugs, building features and building infrastructure to either scale up current features, or to enable us build previously-impossible features. But I agree with you that most businesses (I'v worked with) are in reactive mode, including infrastructure!
ctrl-j 10y ago
> 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. So MDD is an office politics tool? TDD and BDD are development tools that help you write better more maintainable code. If all MDD is saying "put in metrics to help you win arguments with your PM", then I already am a MDD master. I'm not saying measuring and testing aren't important. I'm saying it's not a design paradigm. I don't know of an engineer who doesn't run tests before diving in to solve a problem on an existing system. If you start from scratch, how does MDD help you build a restful API? What about an authentication microservice? Adding a new feature - what metrics can we measure? TDD and BDD BOTH help you with the process of engineering stronger solutions. Saying "measure things and use analytics to make decisions" doesn't really qualify as a paradigm.

by pionar 10y ago

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!
- ctrl-j 10y ago
  If you argue major decisions that way, you're going to get shut down every time. I'm not arguing against measurement or thoughtful decision making. I'm saying it's not a good way to engineer a product. What would you do if Ford practiced this when designing a new car? "Hrm.. metrics show that gas vapors leaking into the cabin lowers sales... I guess in the next version we shouldn't put the gas tank inside the cabin. The previous metrics said it would save money by reducing overall material costs!"
- neeleshs 10y ago
  Im having a hard time to imagine this conversation. Infrastructure projects typically need a lot of buy-in from across teams (due to costs) and are geared to solve specific problems the business faces. This has been my experience in small/medium sized companies which had to juggle among fixing bugs, building features and building infrastructure to either scale up current features, or to enable us build previously-impossible features. But I agree with you that most businesses (I'v worked with) are in reactive mode, including infrastructure!

ctrl-j 10y ago

> 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. So MDD is an office politics tool? TDD and BDD are development tools that help you write better more maintainable code. If all MDD is saying "put in metrics to help you win arguments with your PM", then I already am a MDD master. I'm not saying measuring and testing aren't important. I'm saying it's not a design paradigm. I don't know of an engineer who doesn't run tests before diving in to solve a problem on an existing system. If you start from scratch, how does MDD help you build a restful API? What about an authentication microservice? Adding a new feature - what metrics can we measure? TDD and BDD BOTH help you with the process of engineering stronger solutions. Saying "measure things and use analytics to make decisions" doesn't really qualify as a paradigm.