Faster, Better, Cheaper – The Art of Making Software | Hacker News Reader

Faster, Better, Cheaper – The Art of Making Software

jrsinclair.com

154 pointsjrsinclair23 comments

Nice. Now read this (I think it says the same thing just shorter): We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

That sounds vaguely familiar. ;)

just a shorter version of everything he said in the blog post.

Sure, businesses like working software right now and documentation never. And especially not proof or good design. Pile of technical debt accumulates.

They do not like interactions nor individuals at all. Too unreliable. They prefer processes but in so doing force bad processes and separation of concerns that prevents in depth solutions.

Responding to change without vision causes random changes slowing work down and preventing important ones (churn).

So where is your value on the left?

There will always be a war between developers and sales. Sales always needs a foot in the door - and incomplete software can get them there. The customer (and sales team) might even expect faulty software, but just as long as you can demonstrate some features can be delivered that might be enough to get the sales through (and pay for the better quality).

It's great that we want great software and even make the customer be part of some feedback cycle but sometimes you need to play "dirty" to make your company survive, and making your sales department happy is one of them. A good sales department knows the business and requirements better than any developer and sometimes you need to listen to them and not "agile your way around it".

Too many drinks with the VP Sales guy yesterday. :/

The point of being agile and have continues feedback is exactly pleasing the sales department. Focus on the features they need to close a sale, then everything else.

That is not enough. Typical agile process is also supposed to keep software easy to change, but instead what you get is pushing a prototype into production even before it is finished in the limited feature set.

Then don't create a prototype to begin with. I have had zero issues when clearly communicating these things. If you want me to prototype things, then fine, but I'm not signing it off to production. If they overrule me anyway without a really good reason, I'll find somewhere else to apply my skillset.

Pleasing the sales department to the degree realistically possible, that is, within the constraints of good engineering, technical reality, and team size. That's often less than the sales team wants, though...

Indeed, but that is where we, as engineers, have to stand our ground, and say "not possible". A good executive will then ask, "what do you need to meet the goal?" and you can start to have a productive conversation.

I could go on about this, I have had this argument many times and I have yet to have highups question my competency or dismis my arguments. I do always leave the door open with something along the lines "I can hire 4 developers and 1 QA, minimize time to shipping, but we will drop all current support. We will have significantly more bugs in 1.0 and if they want any major changes a rewrite is needed". If that is what they want, I'm a fool for not delivering, but I also know to start looking for a different job.

> The issue is that estimation and predictability are impossible problems to solve.

Not the first time I read something like that, but it still soothes my nerves every time. I keep feeling like an idiot when I can't answer those inevitable questions from people wearing managerial hats.

Never forget you're not alone in this. This is one of the things many people want to suppress in the experts because there's a big economical interest in those people keeping quiet about these things because that means you can pressure the experts by guilt-tripping them.

Never works on me for years now.

Keep fighting the good fight. I do as well.

99% of the time the problems I've had with business people stemmed from this simple lie:

"I understand you need to make it better and I understand we need to invest now in order to save expenses later. Fine! But let's make it quickly and ugly right now because we need to get to market."

You can predict what I'll say. "Later" never comes. They lie. They are businessmen and they know how to make you feel good about yourself so you can get to work on their interests.

"Why do you need to rework? The thing is working!"

...Of course.

Too cynical, I know -- just venting and that attitude I'm showing here is not representative of how I communicate. I manage to find a common language with most of them but I'd prefer never to have to deal with them in the first place.

That costs me a lot of income lately but I still don't budge.

Faster, Better, Cheaper - pick two.

That's easy. Better and cheaper please.

Slow is only applicable in a few cases.

When you identify the needs and start developing, you must make sure the needs are still there when you finish.

The more time you take, the more likely a competitor can steal your market.

You need serious backing, because you won't make any profit during the initial phase.

Sometimes, being fast is a customer requirement, otherwise, you won't get the job.

Companies like Blizzard Entertainment can get away with "when it is done" but they are the exception rather than the rule.

Almost never the first incumbent takes over a market a in the end. It is a lie propagated in the same way as all the get rich quick schemes.

Blizzard did not invent the RTS. Nor the hack and slash roguelike. What they did is produce polished experiences from the outset. Heck, compare even the silly Overwatch. It is not even close to the first team shooter.

General Electric.

Kodak.

IBM.

Xerox.

All were the first incumbent in their area and were dominant for many decades.

Craiglist even qualifies.

Pretty huge corporations and I'm willing to bet an organ they used very shady techniques to keep themselves on the top. So not really a good comparison.

Apple was small and on the brink of going out of business. There were smartphone-like devices on the market already. They improved on them. I belive that's what your parent commenter is saying.

You and me but this is not what it gets picked usually. Everybody wants fast and cheap because these are the only things that any person (even an unqualified one) can judge. Also they only think about now. They don't realize that cheap now will mean more expensive later when everybody will understand that quality was poor and things need to be redone or at least modified which means more time, so it was not fast, and more money, so it is not cheap. And now is bad too.

So basically free software.

If you have a product that customers want and are willing to pay for, faster and better will almost always end up cheaper in the long run.

In my practice: pick one.

Reply on news.ycombinator.com