3 ms·

Amen. Seen too many devs pursuing the perfect 1-size-fits-all holy grail architecture, only to leave a pile of over-abstracted technical debt in their wake. Q

by mythz 14y ago

Amen. Seen too many devs pursuing the perfect 1-size-fits-all holy grail architecture, only to leave a pile of over-abstracted technical debt in their wake. Quite simply, if you can't understand why and when a particular pattern or methodology is effective, you can't take advantage of it and shouldn't be using it. An experienced programmer is confident in all his choices and able to pick the best tool for any particular situation. Blindly subscribing to religions or Cargo cults just clouds your judgement and leads you to falsely believe that you wield the only hammer that gets all jobs done.

lmm 14y ago
>Seen too many devs pursuing the perfect 1-size-fits-all holy grail architecture, only to leave a pile of over-abstracted technical debt in their wake. Which is a result of the wrong methodology, and what the modern approach tries to prevent. And you know what? It really is better. I don't for a moment believe that everyone was doing agile-type development and then in 1968 they discovered NASA used BDUF and decided to adopt it. Software engineering is a remarkably young field, we really do know things now than we didn't know ten or twenty years ago. If you're following what was the best methodology a year ago, it probably isn't the best methodology now - there is no contradiction there. Just don't for a moment try and tell me that the old ways are better. Because that's really not true.
slantyyz 14y ago
Yes. You can't choose a methodology without considering the personalities and habits of the team members. Unless you have the luxury of replacing an entire team with people who want to work with a particular methodology, dogma gets you nowhere. And I'm only talking about a team. Go up a level or two to the department or organization, and things get even harder.
- HeyLaughingBoy 14y ago
  My god, I wish people understood this. Process Methodology, by and large, exists to create a "quality floor." Follow methodology X and you are likely to have a product that is no worse than Y, for whatever set of metrics Y is. But process does not create skill. Process should exist to provide a framework or a set of limits to work within. It won't make a mediocre developer a superstar, but it will keep him from propagating dumb mistakes out to the customer. As a result, Process results in less improvement from good developers, because they're already operating at a level well above the quality floor. In the end, randomly choosing a methodology without considering the team's personality and culture is a recipe for frustration for some, apathy for others and maybe a small bit of product improvement.
  - slantyyz 14y ago
    >> Process Methodology, by and large, exists to create a "quality floor." I agree. I have this saying that doesn't win me any friends: "Methodologies are for monkeys". (Keep in mind I use that term for project management methodologies and not so much for development methodologies) A lot of big companies want/like trendy methodologies because they assume it lets them to hire less skilled people (i.e., cheaper) and continue to produce quality work. It doesn't. What I have found is that when you have a team of quality senior people with good communication skills and throw them together, they will hash out what processes work best for that team without any need of formalizing their process. This way, everyone gets to work the way they want individually with some adjustments that allow them to work as a group.
einhverfr 14y ago
Additionally the tools are not necessarily all mutually exclusive. I don't see why you can't put real engineering effort into your database and build the app on top of it in an agile way for example.

by mythz 14y ago

lmm 14y ago

>Seen too many devs pursuing the perfect 1-size-fits-all holy grail architecture, only to leave a pile of over-abstracted technical debt in their wake. Which is a result of the wrong methodology, and what the modern approach tries to prevent. And you know what? It really is better. I don't for a moment believe that everyone was doing agile-type development and then in 1968 they discovered NASA used BDUF and decided to adopt it. Software engineering is a remarkably young field, we really do know things now than we didn't know ten or twenty years ago. If you're following what was the best methodology a year ago, it probably isn't the best methodology now - there is no contradiction there. Just don't for a moment try and tell me that the old ways are better. Because that's really not true.

slantyyz 14y ago

Yes. You can't choose a methodology without considering the personalities and habits of the team members. Unless you have the luxury of replacing an entire team with people who want to work with a particular methodology, dogma gets you nowhere. And I'm only talking about a team. Go up a level or two to the department or organization, and things get even harder.

HeyLaughingBoy 14y ago
My god, I wish people understood this. Process Methodology, by and large, exists to create a "quality floor." Follow methodology X and you are likely to have a product that is no worse than Y, for whatever set of metrics Y is. But process does not create skill. Process should exist to provide a framework or a set of limits to work within. It won't make a mediocre developer a superstar, but it will keep him from propagating dumb mistakes out to the customer. As a result, Process results in less improvement from good developers, because they're already operating at a level well above the quality floor. In the end, randomly choosing a methodology without considering the team's personality and culture is a recipe for frustration for some, apathy for others and maybe a small bit of product improvement.
- slantyyz 14y ago
  >> Process Methodology, by and large, exists to create a "quality floor." I agree. I have this saying that doesn't win me any friends: "Methodologies are for monkeys". (Keep in mind I use that term for project management methodologies and not so much for development methodologies) A lot of big companies want/like trendy methodologies because they assume it lets them to hire less skilled people (i.e., cheaper) and continue to produce quality work. It doesn't. What I have found is that when you have a team of quality senior people with good communication skills and throw them together, they will hash out what processes work best for that team without any need of formalizing their process. This way, everyone gets to work the way they want individually with some adjustments that allow them to work as a group.

einhverfr 14y ago

Additionally the tools are not necessarily all mutually exclusive. I don't see why you can't put real engineering effort into your database and build the app on top of it in an agile way for example.