71–80 of 87 posts
Earlier quoted context omitted.
Genetically engineered dogs that excrete sealed tubes will put you out of business.
Robot dogs will put you out of business.
It doesn't mean that there isn't money to be made each step of the way.
Earlier quoted context omitted.
Why is only building for yourself a bit too far? This seems like common sense to me. If you're not using your own product day in day out, you should be.
Because I may not be in the same line of business as my users. For example, my last start-up develops planning software for large agricultural firms. I don't happen to manage a large agricultural firm, nor am I likely to manage one in the near future. Still think I should be using my own product day in day out?
Had I built that software for myself, it wouldn't had have any traction with the employees in that company.
Earlier quoted context omitted.
Why is only building for yourself a bit too far? This seems like common sense to me. If you're not using your own product day in day out, you should be.
Because then PG wouldn't have built Viaweb. He certainly wasn't building it for himself.
Earlier quoted context omitted.
Part of the problem is that talking about the analysis process is like writing a textbook on romance. How do you fall in love? Is there a set of best practices and a six-sigma process? Well, no. It's an art. It depends entirely on the situation and on the parties involved. You get better at it with practice. There are rules of thumb that are definitely helpful, but you have to know when to break them. Unfortunately,…
"How do you fall in love? Is there a set of best practices and a six-sigma process?" I don't know, but "The Six-sigma Process for Romance; Taking the Guesswork out of Finding Love" sounds like the title of a New York Times Bestseller to me.
I'm with several of the commenters. There's a big difference between books and reality. I'm not going as far as edw with his "modeling controls the discussion" (e-gads! Get this man a UML primer and be quick about it!) but there's a long, long way from a guy peddling a book to a guy you'd actually want helping you to do anything.
I'm not throwing books out. Not by any means. Lots of my friends have written software books and I'm peddling one myself nowadays. Got a bookcase full of some good and some not-so-good books. But it's a medium, and the medium has its quirks.
Earlier quoted context omitted.
Why is only building for yourself a bit too far? This seems like common sense to me. If you're not using your own product day in day out, you should be.
Because I may not be in the same line of business as my users. For example, my last start-up develops planning software for large agricultural firms. I don't happen to manage a large agricultural firm, nor am I likely to manage one in the near future. Still think I should be using my own product day in day out?
But if you truly want to build a great product, one that does the things that your clients didn't even know they needed until you wrote it, well, there's only one way to find out about those sorts of requirements - do the job yourself. Your software will never fulfill these unrecognised needs, and will hence never be truly great.
It's back to the whole Mac circa 1982 thing again. No-one would tell you that they needed a graphical interface to their computer if you had asked in 1982.
"Take what's essential, discard the unnecessary, and make it your own."
That's the point I got from Steve's post.
And that's how I dealt with his rambling.
Meta-great post.
Good rant, but I want to talk about dog poop. Surely there must be an enzyme cocktail that can evaporate poop! You would not use it indoors, only for outdoor use. But there must be something that will decompose dog poo super fast. Any organic chemists here?
Earlier quoted context omitted.
"You get with them and "live their lives" and suffer with them, understanding what they must accomplish, how they must do it, and what's stopping them now. " This is a great idea, and the real way to address the problem Steve suggests: Become the business. However, the majority of your criticism of Steve is way off base, because the methods he describes are not strawmen, but the actual methods described in most of th…
...actual methods described in most of the software engineering requirements books... Thank you, Matt. You have just demonstrated my number one concern about the nature of discourse here on hacker news. The issue of "book contents" vs. real world experience. I don't know you and certainly don't mean to pick on you, but calling my criticism of Steve's article "way off base" merits this response... First a little of my…
I think that Mr. Yegge missed the real question - but the rant was worth it. I particularly liked "The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away." I suspect what the "business correspondent" wanted to know was something more like: "My customer wants me to build him a new billing system. Their top managers have some defined…
Earlier quoted context omitted.
Over complicated business requirements are bullshit. What if the requirements are complicated? Go ahead and develop an arbitrage system, a medical claims processing system, or a repetitive shop floor control system without "complicated enough" requirements and see how far you get.
Over-complicated is the same thing as too complicated, which does not put a limit on how complicated a system can be.