News for hackers. Stuff that matters.
Re:It Takes 6 Days to Change 1 Line of Code (2015) by alkonaut on Wednesday December 07, 2016 @04:40AM (#13121466)
> and the result is that the firefighting ends up producing more fires than it puts out.

I usually find that customers

- Prefer getting feature early, even if it's unpolished, meaning ship something broken and fix it later rather than polish and ship something perfect.

- Prefer many, complex features over simplicity/performance in the product.

- Prefer having more bugs, but quick turnaround over having few bugs and a long turnaround.

In all the enterprise scenarios I have worked I have tried to stress the importance of simplicity etc but really all customers have stressed is that they don't mind bugs, crashes or poor performance as long as they can get their work done, and that might depend on that last feature or putting out that last fire.

Re:It Takes 6 Days to Change 1 Line of Code (2015) by pjc50 on Wednesday December 07, 2016 @05:40AM (#13121670)
They say that now. But what happens when they list all the bugs against you when it comes to paying the invoice?
Re:It Takes 6 Days to Change 1 Line of Code (2015) by dalore on Wednesday December 07, 2016 @10:23AM (#13123139)
They say, thanks for fixing all those bugs. They know the bugs exist because they encountered them. Fixing bugs actually looks like work is getting done.

Unlike if you came back to them with a polished product with no bugs, they would be like why am I spending all this money for this time?

Re:It Takes 6 Days to Change 1 Line of Code (2015) by Anthony-G on Wednesday December 07, 2016 @03:38PM (#13125998)
That’s related to the concept expressed by behavioural economist, Dan Ariely: “consumers don’t value goods and services solely by their utility, … but also a sense of fairness relating to how much effort was exerted” [1]. In that quote, I’d probably qualify the word effort as “perceived effort”.

http://danariely.com/2010/12/15/locksmiths/

Re:It Takes 6 Days to Change 1 Line of Code (2015) by wila on Wednesday December 07, 2016 @11:15AM (#13123616)
The customer doesn't know about or understand technical debt.

Any improvements you make down there are just racking up on time spent that makes the bills higher which they will notice. They do not see your improvements, but they will notice it if your much betterer code now introduces a new bug.

Higher bills as your predecessor, slow in fixing and new bugs. That is the moment to worry about getting bills paid, not for fixing fast.

Re:It Takes 6 Days to Change 1 Line of Code (2015) by alkonaut on Thursday December 08, 2016 @01:43PM (#13132880)
The thing is, the existing customers are locked in (or we failed).

The customers we want are those that aren't customers yet. Those customers require features that we don't have yet in order for them to become customers.

It might be the right decision as a business to screw the existing customers by aggregating tech debt in order to grab new market share before the competition does (again this is in a context where a customer has no chance of leaving once on board - which is more or less the case in all enterprise scenarios I have experience from, both web and desktop).

I hate this mentality and as a developer it's terrible - but I can't say that it's the wrong decision to make short term, business wise.

Re:It Takes 6 Days to Change 1 Line of Code (2015) by wila on Wednesday December 21, 2016 @10:13AM (#13229690)
Guess I simply do not share your view. My customers are not locked in, in fact I will go out of my way to make it easy for them, their employees or even another consultant to continue on any work of the work I do and have done for them in the past.

In addition I am not in favor for aggregating technical debt, I suppose I wasn't clear. The article talked about a 1 line fix and that by itself should not trigger a rewrite of a feature, especially not when the fix has to be done now, not next week.

Re:It Takes 6 Days to Change 1 Line of Code (2015) by alkonaut on Wednesday December 07, 2016 @10:14AM (#13123064)
> But what happens when they list all the bugs against you when it comes to paying the invoice.

I have never seen that happen, but then I have never worked on invoiced/project work, only long term enterprise/product dev. Customers license the software, but I suppose there could be some SLA type agreement also for desktop software (which happens to be the case).