[RogerL]

Sure. Friday on LinkedIn I got one of those "recommended jobs" thingies in my story line. It was full of "you should value execution over planning". It pretty much sounded like a 20hr/day sweatshop of fighting endless bugs and chasing the whims of the founders.

Are the VCs listening to this? You are funding people who don't take spending your money very seriously. There is a huge continuum (shall I say gulf) between not over-engineering something when you don't yet have proven market share and just randomly tossing shit together.

[pvdm]

With a few exceptions, I think the VCs are fueling this kind of mentality. It's not really their money. Netscape was the perfect model for this kind of behavior. Just ask JWZ.

http://www.jwz.org/blog/2011/11/watch-a-vc-use-my-name-to-se...

[api]

"you should value execution over planning".

People who hold to this philosophy should practice it while driving. This would reduce the number of people who hold this philosophy.

[ikura]

Or at least reduce the number that arrive at their intended destination...

[UK-AL]

A lot of entrepreneurs, are the engineering equivalent of cowboys. Entrepreneurs who are professional software developers, are quite rare.

[onion2k]

Throwing something together and putting it in front of people aims to answer the question of "what does the customer actually want?" Until you've answered that question you can't build a professional product - otherwise you're building without a defined set of requirements.

Many entrepreneurs I've met hate the fact they're writing utter crap code, but without the budget to make mistakes (e.g. building the wrong thing), you have little choice.

[RogerL]

I am not sure if you are disagreeing with my comment, or expanding on it, so let me clarify.

That was the point of my 'continuum' comment. If you don't know what the customer want, sure, one way to answer that is to prototype things and put it out there. In which case you are certainly not going to worry about whether the current system is scalable and so on.

But.

If your product is the front end to my bank, yes, do DO have to worry about whether it is a professional product or not. Even if it is a silly game, you need to stop and think about what you are going to put out - just hacking some shit together is unlikely to result in a product that people want. That is what we are talking about - think about what you are doing, adapt your strategies to your goal, and so on. Naturally that sometimes leads to substandard architecture - most understand and accept that. But to just run around randomly doing shit? That way lies madness.

Sorry, this is about impossible to capture in a single post, or series of posts. But so many companies have taken the difficulty of requirements definition and somehow conflated that into a 'ready. fire. aim' mentality about all aspects of the business.

edit: for a long time I worked in avionics. This was a vertical silo. Let's ignore the human safety aspect, which of course sways engineering quality immensely, and focus on the silo part. It was mostly really clear when something was a throwaway, and when something had value beyond a single product. For example, code to display an HSI. You could hack that out quickly for a trainer, but hey, look, we work in avionics. Think that just might be useful even if this trainer ends up thrown away? Of course. So, you might put a bit more effort into that part of the project. I wrote code in 94, for a prototype, that is still running today in many different products. Small parts of that code, but the important bits. 'Get Shit Done' doesn't even admit that conversation, whatever the right decision might be (there are certainly budget/time cases where you might just hack it together).

[UK-AL]

I think the best way to pivot and change, is having codebase that you can actually change, without breaking everything.

[absconditus]

Many of us who have had jobs for a long period of time know exactly what problems need solving and how to solve them. What the market wants is not always a mystery.