Which is more important: writing the code right, or writing the right code? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this questionWhen we write code which helps the business, we create value for them, often in the form of profit, market share, etc.
If we write the wrong code, we won't generate this value. We might generate some of it, but we'll be missing out on those big wins.
A 开发者_Python百科recent survey suggested that writing the right code - aligned to what the business want - may be less useful than writing the code right; oiling IT to produce anything, even if it's not well-aligned, to a higher quality.
I've experienced projects which were technically amazing and never made it to production, projects which were buggy on release but helped the business to redefine their strategy, and everything between and vice-versa. What are your experiences, what balance would you recommend and why?
Which is more important: writing the code right, or writing the right code?
At first glance, this might seem like a "which came first, the chicken or the egg?" question but it isn't. If I absolutely have to compare these two, then I would think "writing the right code" is more important. But what is even more important than these two is this: "Writing the code right, for the right code to be written"
Why I think writing the right code is more important? It's because the "writing the right code" decision has to come first, then you can "write the code right" for that. Both of these logically should not conciously happen in the exact same time. Real Example would be: In Sprint Planning the PO decides "what" needs to be done - which is the "right code to be written", and during the Sprint the Team "writes the code right" for the "right code to be written", in the right order of priority.
What are your experiences, what balance would you recommend and why?
I have also coincidently seen the correct user story being worked on in a bad quality way, but it luckily produced huge gains for the business. And I've also seen really high quality code product being scrapped. This all may be coincidence, but there are certain concepts which may make this observation be seen more often. For eg. a concept/practice called "gold plating" where a development Team spends too much time polishing up the code, to a point where even senior developers think it is unnecessary, when what the Team really should do is, move to the user story next in priority. On the other hand, a team which spends very little time refactoring may produce buggy software quickly and it may even bring profits to the business, but "Technical Debt" would eventually kill them, if not now then a few years later, and the loss due to that may be double of the profit they might have made initially!
The survey is not about software per se, but rather IT operations. As such it's hard to draw conclusions from it regarding the software we develop -- it's more useful, perhaps, in determining when to produce the software in-house vs. purchasing an external solution. Clearly when writing code it's best to produce the right code, right. In a nutshell, that's what the agile software movement is all about. Deliver early and get feedback to produce the right code; use unit testing, pair programming, continuous integration, and continual refactoring, or some subset among and of the various agile practices to produce the code right.
If I need to choose, I would go for Writing the right code (you know what you want and you want to build it correctly -- otherwise you are building something else).
But, I would also say Writing the right code in the right way is the way to go.
Obviously, there's no one right answer -- but my preference as an engineer is to try to produce systems that are internally "correct", that evinces good software characteristics (powerful, decoupled, coherent, etc.) The business people will correct me if I'm not doing what they need, and correct me by sending memos and Jira entries; poor quality shows up in much more subtle ways.
If you are asking the question you pose, there was a failure earlier in the process. If you did your job of requirements engineering correctly and have proper access to the proper customers and stakeholders, you shouldn't have to worry (as much) about whether you are writing the right code.
Every doctor will eventually mis-diagnose a symptom as the actual problem instead of its proper place as a symptom of an under-lying problem. That should not be the norm.
If, however, your business clients prevent you from reaching the customer or in some other way impede the requirements engineering process, then your ability to write the code right will give a clear indication that the problem with the development process isn't on your end.
Also, if you're writing the code right, and writing the right code for the requirements that have been specified, then an iterative development approach should indicate fairly early in the process that something else isn't right.
I don't suppose thats count as answering the question, does it? Writing code is the smallest part of a programmer's job, so if we do the other 60-80% of our job right, then we should always be writing the right code and that gives us more time to write the code right as well.
加载中,请稍侯......
精彩评论