3 ms·

This article makes such sweeping generalizations. Customers may not care about the details of the architecture (they may not even know what 'software architect

This article makes such sweeping generalizations. Customers may not care about the details of the architecture (they may not even know what 'software architecture' means), but rest assured they indirectly care about the architecture. As a layperson when it comes to automobile engineering, I only care about whether or not my Toyota works. But as a customer who relies on its safety, I assure you I care a great deal about whether or not it is well architected. As a layperson when it comes to structural engineering, I only care that my house stays up. But it better be well architected. Don't mistake a customer's lack of caring about C# vs Java with them not giving a crap about whether or not your application will suddenly spew their credit card numbers to the world due to a slipshod security model. I don't care what approach Toyota took to form my transmission, but I would sue Toyota if my transmission suddenly broke and it turned out they'd put it together in a sloppy fashion. Like all things, a customer's real care is based on a continuum. I don't care particularly if Reddit or Twitter goes down, but I care a great deal if Bank of America suddenly lowers my balance due to a rounding error. Of course you can get overwhelmed by architectural possibilities. Assess your customers' expectations of your uptime, overall quality, etc. Assess your customers' expectations of your ability to release new features quickly. Assess projected scaling issues. Avoid buzzwords. Adjust accordingly. A foolish building architect could easily spend a year figuring out the ideal materials, but a competent one will still get the building done safely, on time and on budget. Same with software architecture.

derefr 16y ago
> I don't care particularly if Reddit or Twitter goes down, but I care a great deal if Bank of America suddenly lowers my balance due to a rounding error. I believe that, if you are writing the latter kind of software, you already know who you are and what you should be doing (whether or not you actually do it is another matter.) Most software isn't "important": it doesn't affect the user's life or health or wallet or relationships or anything when it screws up. Defaulting to assuming your software needs to be as security/privacy/stability-conscious as online banking, is just as much of a waste of time for the average programmer as assuming every website will get hit with as much web traffic as Facebook/Google/etc. and so needs to be "web-scale." Your company's intranet to-do list won't get a million hits a day, and if it goes down, people will just write things down on paper instead. It can be a 20-line Python script. Really.
- j_baker 16y ago
  Most software isn't important in the sense that it affects their lives. But it can affect their continued use of whatever it is that isn't working.
- bad_user 16y ago
  Every time I tried Foursquare their service was down ("for maintenance" their page said). After ~ 5 attempts in ~ 5 different days I stopped trying. Maybe it was just my luck, but even Twitter has been more reliable for me. I fail to see how this is not important: they haven't won a conversion out of me although I'm still getting spammed by them through my friends. Your company's intranet to-do list won't get a million hits a day, and if it goes down, people will just write things down on paper instead. If that to-do list goes down repeatedly, people will not use it ... it's hard enough to convince them to try it in the first place.
  - derefr 16y ago
    But Foursquare being down, and losing a conversion from you, didn't affect your life any more than if you had just not heard of Foursquare in the first place. "Important" software can actually have negative utility if it's programmed wrong: it can take away your money, make you lose your job, give you a lethal dose of radiation, etc. Most software isn't important in that sense. The applicable advice for startups here is: when you're just starting off, your software can afford to be hella buggy, because (unless you're entirely dependent on viral growth) one lost conversion here and there doesn't do anything more to your product's momentum than any other leak in your funnel. Make a buggy v1.0, sell it to the people who will buy it, and forget about the tiny[1] number of people who check out your 1.0 and write you off because of it. Then, use the money from 1.0 to fix the bugs, and release version 2. Assuming your product survives, most of its lifetime will be spent beyond version 2—and so most of the customers your product gets (or loses), it will get (or lose) based on how version ≥2 works, not on how buggy 1.0 was. [1] The people who will write your 1.0 off will be "tiny" in an absolute, not relative sense. You might be losing 50% of customers because your software is crap—but if that 50% is 50% of 100 people per month, then you still aren't doing yourself much damage. Once you have 50000 satisfied users, those 700 or so people who you scared away in the first seven months will be entirely forgotten. Heck, they might even come back again, if their friends are telling them about all the features of 2.0.

derefr 16y ago

> I don't care particularly if Reddit or Twitter goes down, but I care a great deal if Bank of America suddenly lowers my balance due to a rounding error. I believe that, if you are writing the latter kind of software, you already know who you are and what you should be doing (whether or not you actually do it is another matter.) Most software isn't "important": it doesn't affect the user's life or health or wallet or relationships or anything when it screws up. Defaulting to assuming your software needs to be as security/privacy/stability-conscious as online banking, is just as much of a waste of time for the average programmer as assuming every website will get hit with as much web traffic as Facebook/Google/etc. and so needs to be "web-scale." Your company's intranet to-do list won't get a million hits a day, and if it goes down, people will just write things down on paper instead. It can be a 20-line Python script. Really.

j_baker 16y ago
Most software isn't important in the sense that it affects their lives. But it can affect their continued use of whatever it is that isn't working.
bad_user 16y ago
Every time I tried Foursquare their service was down ("for maintenance" their page said). After ~ 5 attempts in ~ 5 different days I stopped trying. Maybe it was just my luck, but even Twitter has been more reliable for me. I fail to see how this is not important: they haven't won a conversion out of me although I'm still getting spammed by them through my friends. Your company's intranet to-do list won't get a million hits a day, and if it goes down, people will just write things down on paper instead. If that to-do list goes down repeatedly, people will not use it ... it's hard enough to convince them to try it in the first place.
- derefr 16y ago
  But Foursquare being down, and losing a conversion from you, didn't affect your life any more than if you had just not heard of Foursquare in the first place. "Important" software can actually have negative utility if it's programmed wrong: it can take away your money, make you lose your job, give you a lethal dose of radiation, etc. Most software isn't important in that sense. The applicable advice for startups here is: when you're just starting off, your software can afford to be hella buggy, because (unless you're entirely dependent on viral growth) one lost conversion here and there doesn't do anything more to your product's momentum than any other leak in your funnel. Make a buggy v1.0, sell it to the people who will buy it, and forget about the tiny[1] number of people who check out your 1.0 and write you off because of it. Then, use the money from 1.0 to fix the bugs, and release version 2. Assuming your product survives, most of its lifetime will be spent beyond version 2—and so most of the customers your product gets (or loses), it will get (or lose) based on how version ≥2 works, not on how buggy 1.0 was. [1] The people who will write your 1.0 off will be "tiny" in an absolute, not relative sense. You might be losing 50% of customers because your software is crap—but if that 50% is 50% of 100 people per month, then you still aren't doing yourself much damage. Once you have 50000 satisfied users, those 700 or so people who you scared away in the first seven months will be entirely forgotten. Heck, they might even come back again, if their friends are telling them about all the features of 2.0.