4 ms·

"Use Tracer Bullets to Find the Target Tracer bullets let you home in on your target by trying things and seeing how close they land." All the other tips I ap

by agentgt 10y ago

"Use Tracer Bullets to Find the Target Tracer bullets let you home in on your target by trying things and seeing how close they land." All the other tips I appreciate but embarrassingly I have hard time with the analogy on this one (besides the bullet reference). I mean I think I get it but I can't figure out how it maps to anything I have done. I would say it is like a "software spike" [1] but somehow the analogy description doesn't fit. Maybe someone has a real world example? [1]: https://en.wikipedia.org/wiki/Spike_(software_development) https://en.wikipedia.org/wiki/Spike_(software_development)

zevyoura 10y ago
Prototypes: http://www.artima.com/intv/tracer.html http://www.artima.com/intv/tracer.html
cjcenizal 10y ago
I think this correlates strongly with the idea of "Defaulting to Yes". If someone has an idea or a suggestion, your default position should be, "Let's try it and find out" instead of the unfortunately more common "That won't work because..." response. Discussion is good (because ideas are surfaced and knowledge is shared) but long discussions are bad (because action is delayed). Action is good because that's how you learn things. By adopting an "Let's try it" attitude, you can move from discussion to action more quickly.
softawre 10y ago
Huh. I always interpreted this as a sort of binary search algorithm you apply when working out a feature or trying to find a bug. "I know the bug happens between this and this, so lets try this - nope, before then. Divide and conquer.
ctb_mg 10y ago
I work with a customer who is notorious for not defining requirements. Their culture is that everyone is either too busy or not knowledgeable enough of all the working parts of a system to define requirements. It's a culture problem over there. The tool I work on generates reports. Rather than defining requirements for reports, the only way to make progress is to understand their general needs through conversation, then provide them a draft report - your best guess. They tell you what to change or what they don't want, then you make changes and provide another draft. When enough tracer bullets are shot, you arrive at the report they actually need.
- daheza 10y ago
  Aren't at this point you doing the job of two people? I have a coworker who would say this when the requirements are well defined. He would say its our job to build the requirements that are given to us. Our job is not to create / define a product. He would often follow this up by saying our company is worth X Billions of dollars, they can afford to hire a Business Analyst/ Better Product Manager. Personally I don't agree with this. It goes against my core beliefs to make something that I don't believe is good for the end user. I have a hard time however coming up with arguments on why we should as a developer spend our time creating basically a product plan.
  - jon-wood 10y ago
    I've worked in environments where everything is specified up front and ones where nothing is specified beyond a vague idea of the end goal. I find the latter far more honest, at least in the context of startups. My experience is that most people don't know how something should work until they see one version of how it could work, from there we can start zeroing in on the actual solution by chopping and changing things.
  - ctb_mg 10y ago
    > Aren't at this point you doing the job of two people? ... our company is worth X Billions of dollars, they can afford to hire a Business Analyst/ Better Product Manager. Yes, definitely. The difference is that in my situation we are a software contractor, not a software development company that owns its products. If we don't work with the customer to discover and build what they want, then it doesn't get built, which means we've lost potential work.
  - jerven 10y ago
    I understand how you feel. You are being hired to solve problems, and figuring out what to solve is a key part of the job. Solving problems is your aim, writing code is only helpful if it solves the problem. I love the days where I get into the office someone ask me streamline something, and all that really is required is a whiteboard, some pens and no code ever. Solving the urgent business issue at a cost of 30 minutes talking and 5 dollars of pens ;) Hiding developers behind analysts and product managers makes everyones job less fun. In my first job we had analysts, product managers, user councils making specifications. Specifications that where terrible and the developers in the team would have loved to do this iterative design with the end users, because the software would have been better fit for use. For me that was a soul sucking experience. Much better to be able to understand why the software needs to exist and how to make it good for users and the organisation (not always 1:1 mapping either) Wanting perfect specs is a good way to limit your career as a developer. Because that way you will never be more than a glorified type writer with a analyst to hold your hand. Solving the whole business problem from start to end is the way to grow professionally. Also perfect specs are impossible :( so iterating with your users is the fast way to good enough for business applications. If you want perfect specs write sudoko solvers...
kolme 10y ago
When I read that chapter of the book I was super struck, because I've been doing this kind of thing intuitively for many many years without knowing it was even a thing. It goes like this: instead of building software parts independently to completion, you start by building just the bare bones: classes, functions and other things you will need, define the interfaces early and connect those parts. At this point classes have empty methods and sometimes return dummy data. Then I go from the bottom up, fleshing out the methods, and I can start to see some end results from the outside. It may seem like it's poor's man TDD (verifying your code as you write it, but without actually writing tests). But one advance of this technique is, that you can put the architecture to test early in the development. I have discovered many design issues this way. Without this "tracing bullet", I have seen things like this happen: team discusses design on the whiteboard, and after a rough UML concept, each developer goes on to write a separate part of the system. After the first pieces are completed, issues arise when trying to make parts play together, some situations where not considered, the design is not flexible enough to cover all cases. Heavy refactoring of freshly written code ensues. Real world example: you want to write a web shop. You make a rough sketch of your design. It'll have a few models: User, ShoppingCart, Product. Also a few controllers and views. In your empty controller, you create some dummy instances of your models. Make them interact, and put the result in the view. The view shows some unstyled cart info. And voilà, you've got a tracing bullet. You've got the most interesting bits of the application sketched and connected. Now you can start fleshing out your models, controllers and views and see the progress in the browser.
- deleted 10y ago
  [deleted]

by agentgt 10y ago

zevyoura 10y ago

Prototypes: http://www.artima.com/intv/tracer.html http://www.artima.com/intv/tracer.html

cjcenizal 10y ago

I think this correlates strongly with the idea of "Defaulting to Yes". If someone has an idea or a suggestion, your default position should be, "Let's try it and find out" instead of the unfortunately more common "That won't work because..." response. Discussion is good (because ideas are surfaced and knowledge is shared) but long discussions are bad (because action is delayed). Action is good because that's how you learn things. By adopting an "Let's try it" attitude, you can move from discussion to action more quickly.

softawre 10y ago

Huh. I always interpreted this as a sort of binary search algorithm you apply when working out a feature or trying to find a bug. "I know the bug happens between this and this, so lets try this - nope, before then. Divide and conquer.

ctb_mg 10y ago

I work with a customer who is notorious for not defining requirements. Their culture is that everyone is either too busy or not knowledgeable enough of all the working parts of a system to define requirements. It's a culture problem over there. The tool I work on generates reports. Rather than defining requirements for reports, the only way to make progress is to understand their general needs through conversation, then provide them a draft report - your best guess. They tell you what to change or what they don't want, then you make changes and provide another draft. When enough tracer bullets are shot, you arrive at the report they actually need.

daheza 10y ago
Aren't at this point you doing the job of two people? I have a coworker who would say this when the requirements are well defined. He would say its our job to build the requirements that are given to us. Our job is not to create / define a product. He would often follow this up by saying our company is worth X Billions of dollars, they can afford to hire a Business Analyst/ Better Product Manager. Personally I don't agree with this. It goes against my core beliefs to make something that I don't believe is good for the end user. I have a hard time however coming up with arguments on why we should as a developer spend our time creating basically a product plan.
- jon-wood 10y ago
  I've worked in environments where everything is specified up front and ones where nothing is specified beyond a vague idea of the end goal. I find the latter far more honest, at least in the context of startups. My experience is that most people don't know how something should work until they see one version of how it could work, from there we can start zeroing in on the actual solution by chopping and changing things.
- ctb_mg 10y ago
  > Aren't at this point you doing the job of two people? ... our company is worth X Billions of dollars, they can afford to hire a Business Analyst/ Better Product Manager. Yes, definitely. The difference is that in my situation we are a software contractor, not a software development company that owns its products. If we don't work with the customer to discover and build what they want, then it doesn't get built, which means we've lost potential work.
- jerven 10y ago
  I understand how you feel. You are being hired to solve problems, and figuring out what to solve is a key part of the job. Solving problems is your aim, writing code is only helpful if it solves the problem. I love the days where I get into the office someone ask me streamline something, and all that really is required is a whiteboard, some pens and no code ever. Solving the urgent business issue at a cost of 30 minutes talking and 5 dollars of pens ;) Hiding developers behind analysts and product managers makes everyones job less fun. In my first job we had analysts, product managers, user councils making specifications. Specifications that where terrible and the developers in the team would have loved to do this iterative design with the end users, because the software would have been better fit for use. For me that was a soul sucking experience. Much better to be able to understand why the software needs to exist and how to make it good for users and the organisation (not always 1:1 mapping either) Wanting perfect specs is a good way to limit your career as a developer. Because that way you will never be more than a glorified type writer with a analyst to hold your hand. Solving the whole business problem from start to end is the way to grow professionally. Also perfect specs are impossible :( so iterating with your users is the fast way to good enough for business applications. If you want perfect specs write sudoko solvers...

kolme 10y ago

When I read that chapter of the book I was super struck, because I've been doing this kind of thing intuitively for many many years without knowing it was even a thing. It goes like this: instead of building software parts independently to completion, you start by building just the bare bones: classes, functions and other things you will need, define the interfaces early and connect those parts. At this point classes have empty methods and sometimes return dummy data. Then I go from the bottom up, fleshing out the methods, and I can start to see some end results from the outside. It may seem like it's poor's man TDD (verifying your code as you write it, but without actually writing tests). But one advance of this technique is, that you can put the architecture to test early in the development. I have discovered many design issues this way. Without this "tracing bullet", I have seen things like this happen: team discusses design on the whiteboard, and after a rough UML concept, each developer goes on to write a separate part of the system. After the first pieces are completed, issues arise when trying to make parts play together, some situations where not considered, the design is not flexible enough to cover all cases. Heavy refactoring of freshly written code ensues. Real world example: you want to write a web shop. You make a rough sketch of your design. It'll have a few models: User, ShoppingCart, Product. Also a few controllers and views. In your empty controller, you create some dummy instances of your models. Make them interact, and put the result in the view. The view shows some unstyled cart info. And voilà, you've got a tracing bullet. You've got the most interesting bits of the application sketched and connected. Now you can start fleshing out your models, controllers and views and see the progress in the browser.

deleted 10y ago
[deleted]