3 ms·

Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I w

by mbesto 11y ago

Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I work with a variety of people who have very little empathy for developers, but effectively hold the purse strings on technology decisions. These people (which largely outnumber programmers btw) see the world in black and white -- things either work or they don't. Software development to them is a black box. > The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) This is pretty much 90% of the software systems and projects that exist today. Don't let the headlines of TechCrunch fool you. The world outside SV doesn't sit in Google, it sits in terminal screens and mainframes. All that money SAP, IBM and Oracle is making is all made by replacing existing systems (whether software or pen and paper). The people making the decisions don't care about MVPs or what screens look like. They want to increase efficiencies aligned with the objections of their role and not get fired for doing it. When I tell a trader at an asset management company they can't enter in incorrect values for a stock trade because we'll need to fix the data quality issue on our backend, they tell me "f--- off" because they'll simply pay their way out of that discrepancy. So I hear you, but what you're suggesting exists in very few organizations (globally) or in a vacuum.

ebiester 11y ago
They're replacing the existing system because the interaction of programmers and users made an unusable system that didn't account for the business needs. Unfortunately, the people in control of the pursestrings don't have the same day-to-day perspective of the people actually using the system. I've seen documented processes be completely divorced from reality. The real challenge in these systems is uncovering the true business, and the true business isn't understood except as a collective. It is challenging to tell a director that they don't understand their own business, however. I've worked in a lot of internal IT shops throughout my career, and it is only recently that I've worked on B2C applications. That's why I explicitly say that replacing an existing system requires more iteration, not less. How many times have you seen a user exploit a bug to get their work done and be angry when it's "fixed?" The real bug is that the business didn't understand their own process. My job, when I was in internal applications, was to cut through the bullshit and really understand how the business was run. And anyone who thinks they can analyze the problem up front and give a precise estimate for how long it will take is delusional.

by mbesto 11y ago

ebiester 11y ago

They're replacing the existing system because the interaction of programmers and users made an unusable system that didn't account for the business needs. Unfortunately, the people in control of the pursestrings don't have the same day-to-day perspective of the people actually using the system. I've seen documented processes be completely divorced from reality. The real challenge in these systems is uncovering the true business, and the true business isn't understood except as a collective. It is challenging to tell a director that they don't understand their own business, however. I've worked in a lot of internal IT shops throughout my career, and it is only recently that I've worked on B2C applications. That's why I explicitly say that replacing an existing system requires more iteration, not less. How many times have you seen a user exploit a bug to get their work done and be angry when it's "fixed?" The real bug is that the business didn't understand their own process. My job, when I was in internal applications, was to cut through the bullshit and really understand how the business was run. And anyone who thinks they can analyze the problem up front and give a precise estimate for how long it will take is delusional.