Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Uh, the code does matter in almost all circumstances. That's because in most cases you're not so much solving something unsolved as providing a lower cost solution via software. The cost of the software (both in terms of initial development and ongoing maintenance) is a factor.

If your problem domain is totally mapped out, maybe any solution that is quick to implement will work. If your problem domain is in any way nebulous or changing, well architected software will save you a lot of money responding to changes, and ongoing maintenance will obviously be cheaper if it's easily testable and robust.



I think the parent's point (though I could be reading my own thoughts into it), is that the things you mention only matter to the user if it directly affects them. An end user couldn't care less what the maintenance costs are if they aren't passed on to them in some way. If they are, then its completely in the interests of the company to have easy to maintain software. Or if changes are time-sensitive and the company is unable to keep up which change requests. If all that's invisible to "users" (or internal stakeholders), it really doesn't matter how much the boots on the ground hate the software.

But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: