3 ms·
I'm sorry, but the management scenarios seem completely backwards. May be it's my background (service gamedev and web SAAS-like apps), but shipping a feature is
by golergka 5y ago
I'm sorry, but the management scenarios seem completely backwards. May be it's my background (service gamedev and web SAAS-like apps), but shipping a feature is only a beginning — you have to test, measure, modify, repeat. If you write bad code, this loop will get long and expensive, your team won't reach your financial targets and the project will be closed. But if you manage to do that quickly and without distracting too much time on bugs — that directly translates to earning more money and being able to grow the team size.
- pindab0ter 5y agoI don’t know if these scenarios are so backwards. As the article hints to it can be hard to distinguish code of high quality from what I’ll call code of ‘high effort [but low quality]’, especially for management. As someone else pointed out: People have trouble seeing negative space.
- golergka 5y agoAs I described, there's no need for anybody to make that distinction. Good code is good because it helps achieve business objectives better. Free market is all that is required for it to win in the end.
- neolefty 5y agoThat would be nice. However, a big problem is the opacity of engineering, especially software engineering. It can be hard to tell the quality of code from the outside, and the less technical you are, the harder it is to see. There are signs of course, such as the number of bugs, but it can be hard to tell the difference between style and quality.
- golergka 5y ago> It can be hard to tell the quality of code from the outside You don't need to. Let the results speak for themselves.