4 ms·

> "I'd never actually used kafka before, and I have a rule with projects like this that any new technology has to be put in first just in case there are unknown

> "I'd never actually used kafka before, and I have a rule with projects like this that any new technology has to be put in first just in case there are unknown unknowns that affect the design." I have been doing the same intuitively for as long as I can remember but never stopped to realize this or why. I wonder what else I've learned by doing like this that now I use unconciously.

aw3c2 10y ago
This is exactly how I develop. Prototype the hard parts first, if they work, good, if not, serious redesign is needed. It would be a waste of resources to focus on the easy parts first.
lucb1e 10y ago
I think Jeff Atwood (known from CodingHorror and StackOverflow) once talked about "de-risking" a project. I'm not sure if this is a general, well-known business technique, but from all the business things I've had in school, this was never any. It made a lot of sense to me too and having a term to throw around helps convincing others that it's a good idea. Teachers typically want to first make up requirements and use-cases, then functional design, then technical design, then either code and tests or first tests then code (depending on the teacher)... Basically, you wait till 60-70% of the work is done to discover design flaws. Later on we had some Agile stuff as well, but more as a "this also exists" rather than "this is how it's done". Doing some prototyping and benchmarking to see whether something works at all was never part of anything. One, exactly one subject ever had a performance requirement: 1000 simultaneous users in a multiplayer game. And it had to work over Java RMI (which makes no sense at all). I was the only person of two classes who pushed for (and was finally granted) the use of raw sockets. I was the only person who took this as a challenge and ran thousands of prototype clients on the school's computing cluster on a Saturday night so I'm not taking anyone's compute time. They never even looked at it. But next Wednesday is the last thing I will ever have to do for that school (unless I have to resit) and I'm so happy I'm done with their shit and can do my own thing next. Properly.
- franciscop 10y ago
  I can see though how arguably it's more applicable to personal or startup (flexible, able to pivot) projects, not so much to medium-big companies. I can see how it might be more important to implement it regardless of it being 1h or 1 week than asking whether or not it's a good idea to implement it. And also arguably the university teaching focus on these companies. That is why you have all of these fancy ways of encapsulating dependencies and wrapping them into oblivion. Funnily enough a really similar thing happens in other degrees. I studied Industrial Engineering and can calculate whatever you want about the cinematics of a robot arm but it wasn't until I set up with some friend to learn how to make one from scratch that we really knew what it was all about.

aw3c2 10y ago

This is exactly how I develop. Prototype the hard parts first, if they work, good, if not, serious redesign is needed. It would be a waste of resources to focus on the easy parts first.

lucb1e 10y ago

I think Jeff Atwood (known from CodingHorror and StackOverflow) once talked about "de-risking" a project. I'm not sure if this is a general, well-known business technique, but from all the business things I've had in school, this was never any. It made a lot of sense to me too and having a term to throw around helps convincing others that it's a good idea. Teachers typically want to first make up requirements and use-cases, then functional design, then technical design, then either code and tests or first tests then code (depending on the teacher)... Basically, you wait till 60-70% of the work is done to discover design flaws. Later on we had some Agile stuff as well, but more as a "this also exists" rather than "this is how it's done". Doing some prototyping and benchmarking to see whether something works at all was never part of anything. One, exactly one subject ever had a performance requirement: 1000 simultaneous users in a multiplayer game. And it had to work over Java RMI (which makes no sense at all). I was the only person of two classes who pushed for (and was finally granted) the use of raw sockets. I was the only person who took this as a challenge and ran thousands of prototype clients on the school's computing cluster on a Saturday night so I'm not taking anyone's compute time. They never even looked at it. But next Wednesday is the last thing I will ever have to do for that school (unless I have to resit) and I'm so happy I'm done with their shit and can do my own thing next. Properly.

franciscop 10y ago
I can see though how arguably it's more applicable to personal or startup (flexible, able to pivot) projects, not so much to medium-big companies. I can see how it might be more important to implement it regardless of it being 1h or 1 week than asking whether or not it's a good idea to implement it. And also arguably the university teaching focus on these companies. That is why you have all of these fancy ways of encapsulating dependencies and wrapping them into oblivion. Funnily enough a really similar thing happens in other degrees. I studied Industrial Engineering and can calculate whatever you want about the cinematics of a robot arm but it wasn't until I set up with some friend to learn how to make one from scratch that we really knew what it was all about.