4 ms·

> Work somewhere where software is the main product and not just a cost center. I've done both and I can't say one is better than the other. I've worked on

by hasbot 9y ago

> Work somewhere where software is the main product and not just a cost center. I've done both and I can't say one is better than the other. I've worked on software products where marketing couldn't figure out how to sell it and kept changing the core functionality. Or where the CEO kept shoving his ludicrous ideas onto development. I've worked on rewarding IT projects where I worked very closely with the users and was very happy to see my work help them perform their day-to-day jobs. I've also worked on slog IT projects where the users had no idea what they wanted and we kept churning. After 28 years, I ended up preferring working close to the actual users.

fixed_carbon 9y ago
"Marketing...kept changing the core functionality" "CEO kept shoving his ludicrous ideas onto development" Check and check. There's also my personal favorite: marketing informs the dev team they've just inked a big contract with a tight deadline for features that were never discussed with the dev team. "We kinda told them we already had those features but hadn't released them yet. Can you guys build that real quick like?"
- pvdebbe 9y ago
  Classic. Our supports operative just happened to promise full IE support (we promise only Firefox) just like that.
walljm 9y ago
> After 28 years, I ended up preferring working close to the actual users. This is key.
- sgt101 9y ago
  this! but also note users and access to them is what "IT" have and "software" often struggles with. Run some field trials, do interviews and field visits to support requirements analysis...
lliamander 9y ago
Interesting! I switch very early in my career to working for product companies because I saw no other way to have a rewarding career as developer. So far it's worked out pretty well for me. However, recently I read Developer Hegemony[0], which seems to describe a path for IT developers to also have rewarding careers. My current thinking is that the Agile philosophy definitely contributes both to successful projects and to satisfying careers for IT developers (Agile came primarily from that world of software development) but only when developers and users are equal partners. That generally only happens when the developers are independent consultants who can speak the language of business. [0]https://leanpub.com/developerhegemony https://leanpub.com/developerhegemony
- collyw 9y ago
  The problem being that no one can actually define what agile actually is. (Or rather everyone can, but there is no consistent definition).
  - lliamander 9y ago
    Yep, it's a problem, and adding my own "what I think agile actually is" would only add to the noise. However, I do think that the original signers of the manifesto were onto something. My recommendation for people is, rather than learning an official methodology, that they go and read the writings of the various different signers. Get an understanding of what it meant for them at the time that they signed the manifesto. Martin Fowler has commented that one of the other names they thought about calling their movement was "conversational software", in the sense that software development process was an ongoing conversation between the developers and the users of the system. The point I gleaned from the book I mentioned was that (in the general case) the power politics of most IT organizations prevents the development process from every being a real conversation. As I understand it, many of the signers were independent consultants at the time of signing (or helped lead IT consultancies) and could speak the language of business. It seems to me that perhaps this put them in a more "peer" relationship with the business stakeholders, and allowed the development approach to be more conversational.

by hasbot 9y ago

fixed_carbon 9y ago

"Marketing...kept changing the core functionality" "CEO kept shoving his ludicrous ideas onto development" Check and check. There's also my personal favorite: marketing informs the dev team they've just inked a big contract with a tight deadline for features that were never discussed with the dev team. "We kinda told them we already had those features but hadn't released them yet. Can you guys build that real quick like?"

pvdebbe 9y ago
Classic. Our supports operative just happened to promise full IE support (we promise only Firefox) just like that.

walljm 9y ago

> After 28 years, I ended up preferring working close to the actual users. This is key.

sgt101 9y ago
this! but also note users and access to them is what "IT" have and "software" often struggles with. Run some field trials, do interviews and field visits to support requirements analysis...

lliamander 9y ago

Interesting! I switch very early in my career to working for product companies because I saw no other way to have a rewarding career as developer. So far it's worked out pretty well for me. However, recently I read Developer Hegemony[0], which seems to describe a path for IT developers to also have rewarding careers. My current thinking is that the Agile philosophy definitely contributes both to successful projects and to satisfying careers for IT developers (Agile came primarily from that world of software development) but only when developers and users are equal partners. That generally only happens when the developers are independent consultants who can speak the language of business. [0]https://leanpub.com/developerhegemony https://leanpub.com/developerhegemony

collyw 9y ago
The problem being that no one can actually define what agile actually is. (Or rather everyone can, but there is no consistent definition).
- lliamander 9y ago
  Yep, it's a problem, and adding my own "what I think agile actually is" would only add to the noise. However, I do think that the original signers of the manifesto were onto something. My recommendation for people is, rather than learning an official methodology, that they go and read the writings of the various different signers. Get an understanding of what it meant for them at the time that they signed the manifesto. Martin Fowler has commented that one of the other names they thought about calling their movement was "conversational software", in the sense that software development process was an ongoing conversation between the developers and the users of the system. The point I gleaned from the book I mentioned was that (in the general case) the power politics of most IT organizations prevents the development process from every being a real conversation. As I understand it, many of the signers were independent consultants at the time of signing (or helped lead IT consultancies) and could speak the language of business. It seems to me that perhaps this put them in a more "peer" relationship with the business stakeholders, and allowed the development approach to be more conversational.