June 14, 2008 at 1:40 pm
Comments posted to this topic are about the item Do You Want to Be Right?
June 14, 2008 at 5:16 pm
I don't know, Steve... Good peoplem like yourself, keep saying that good enough is enough. That refactoring code should be carefully considered. That you need to get things done and you can tune them later.
I just can't bring myself to think that way. We've used 3rd parties that are famed for getting things done "on time" only to find that their crap code hits a tipping point six months later and becomes a DBA's performance nightmare.
Too many folks know the cost of everything and the value of nothing. Too many folks want things real bad and don't understand that they're gonna get it that way... real bad. People need to start standing up to management and say "NO! We can't do it RIGHT in that amount of time." Of course, there will always be the scab or the coward that turns in code on time everytime, even if it doesn't actually work, just to say "Well I did it on time". Yeah... you made a train wreck, right on time... dill weed.
People need to start to realize what the cost of doing it again means.
Like you said, it really doesn't take that much longer to do it right... so what the hell is wrong with doing it right the first time?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2008 at 5:32 pm
The problem is what's "right"?
It's tough to decide and honestly I'm not sure how many places I'd say that something is "right" and not just slightly "better". I don't think being effective means writing bad code. It's that you balance the speed of completing the solution with the quality. It seems often I've found developers spending extra time to build an elegant, "best" solution when they could have completed things quicker if they'd put completed at a slightly higher priority than having beautiful code.
When I look at out the world, often good enough is fine and it works well. The extra cost (and time) to squeeze out the last 10 or 20% of improvement doesn't always make sense. Some people really appreciate it and that's fine, but it doesn't really matter for many people and situations.
My vote is that you should write good code. You should be improving your skills and getting a little better each time you build a new system, but you also have to get it done as quickly as possible.
June 14, 2008 at 5:37 pm
Heh... I could probably live with leaving out 10-20% improvement... too bad it's never that low. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2008 at 5:49 pm
You know... Sergiy is right. We expect "perfect" from everyone except the people that write software. We're talking about leaving out the 10-20% for software... what would you think if the mechanic that rotated your tires only put 4 or the 5 lug nuts back on your wheels? He only left out 20%. How about a tune up? What if the mechanic returned your vehicle with only 7 out of 8 of the cylinders firing? What the hell... he only left out 12.5%. How about if the mechanic left grease marks all over the steering wheel or left his greasy rags in the engine compartment. That's even less than 1% of the total job. How about if the mechanic left only 1 greasy footprint on the carpet? That's well within the tolerance of 10-20%.
No... the code needs to be right. It needs to not only solve the problem that it was reqired to solve, it must be maintainable (extremely readable with documentation included!), it must be performant, and it must be scalable over time. Leaving out what some folks refer to as the "elegant 10-20%" is a bloody mistake because it's not really elegant to do things 100% right... it should be required!
You are correct, Steve. It depends on what the perception of "right" is... it's very unfortunate for most companies that so many developers set the bar so very low.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2008 at 7:24 pm
I think Jeff kind of put it together without quite saying it. In my mind, in order to BE effective, you have to be right. It's a lot like a conversation that was occurring earlier this week: we often lie to ourselves, and justify trying to slap something together, by promising (to ourselves) that we will come back and make this right "in a little while".
The reality often turns out that once you put it down, put it in play, you just plain don't come back and fix it. How could you - you're off making the next set of compromises to deal with yet another unrealistic expectation that someone has yessed past upper management.
The technical debt you incur by not putting together something TRULY "good enough" will quickly get out of hand if you do not set that "good enough" bar high enough. The small gains in time you might have seen during phase I will get swallowed up by all of the downtime, and rebuilding time you will need to do in Phases II through ??? by having that deficient piece in your design.
So - be effective, once you're right. If it take a little longer to put the right thing in place (notice I didn't say "perfect" - I said RIGHT), do it and sleep soundly knowing that it isn't timebombed, crippled, ludicrously obscure, etc.... in other words - by touching it once and getting it "right", you are being effective, since you're saving yourself and your team much in the way of future support time, refactoring time, etc....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 14, 2008 at 7:43 pm
Actually, I don't expect perfection from everyone, but I would expect it to be done right. Right does not equal perfection.
I have written code that was right, it met the requirements of the users and did the job expected. Now, several years later, I have learned things that I didn't know back then, that would make the code I wrote earlier better and more performant. Does that mean the code I wrote is no longer right?
As Steve said, we need to meet the requirements of the project. We also need to continue to learn, and as we learn we will (hopefully) find new ways of doing things that make our code better, more performant, and even (perhaps) able to do it in the same time as the old ways we did things. This is how we become better at what we do.
I have learned quite a few things right here on SSC that I feel make me a better developer and DBA. I can see that there is code I have developed in the past that could now be written differently that would improve its performance and scalability, unfortunately I can't go back and fix it (previous employer). I can, however, take what I've learned and use it future projects and assignments.
😎
June 14, 2008 at 9:23 pm
Matt Miller (6/14/2008)
In my mind, in order to BE effective, you have to be right.
Absolutely beauf! Couldn't have (and, obviously didn't) said it any better. I may have to add that to my already-too-long signature... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2008 at 9:40 pm
Like Steve said earlier, this brings up the subject of "What is right" and that's where most of the contention comes up. To me, "Right" not only means that it works as designed, but it's also well formatted, easy to read, fully documented code which is also performant, scalable, and handles errors correctly. It's always something I'm proud to put my name on.
Near the bottom end of the spectrum, "Right" simply means "Pretty sure it's functionally correct", period.
At the very bottom of the spectrum, "Right" means "I got it in on time... let someone else test it... I've got more cursors to write."
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2008 at 10:11 pm
Here's part of the problem with "right". What to me was well written performant code, still could have been written better today because of the things I have learned since writing that older code.
Is the code I wrote still right, or is it now wrong? If it still meets the needs of the users and still performs as well now as it did when it was first implemented, is it still right or is it now wrong since I now know a better, more performant way to accomplish the same task?
I agree that code should be well written, well documented, well tested, performant. But you also have limits to how much time you have to work on projects. Sometimes the first way you come up with something may not be the best, but it does provide you with the correct results. This is important to identify. Once you know what you need to return, you should be able to find better, more efficient ways to do so. I realize that there are folks that would say, I have the right answer, time to move on without further review of the solution. That ISN'T right (or it is, but it is at the bottom of the scale as described by Jeff). How long do you keep looking for the optimum solution, when is it right?
With all the constraints on developers or DBA's time, there has to be a point where you have to say I have found the best solution possible at this time, and move on to other tasks. Documenting what you have, ensuring the code is well written so others can easily figure out what your are doing are important. At some point, requirements may change, data structures may change, any number of other events may occur that will affect a piece of code and need to be revisited.
I am actually facing that issue now with code I wrote a couple of years ago. We are looking at changes to the source of the data. Instead of using massaged data, we are going back to the source of the data. With this, I am taking things I have learned and rewriting the code to be more efficient and performant; and so far, I seem to be doing a pretty good job with the new code. I still have a few minor tweaks, but that is more cosmetic (identifying a few additional data elements that may be needed), than performance related.
😎
June 15, 2008 at 1:59 pm
It sounds like we're all saying something similar. You want to have the best code you can write, but it also has to get done.
The thing you can't do is waste too much time getting the last bit of performance out of things.
We used to argue about how long you tune things. An extra $2-3k in tuning time might not be that long, but it could buy quite a bit of hardware. Developer cost is much more expensive than hardware, so at some point you want to through silicon resources at the issues.
With the database it's different since it's a limited resource. Still hard to scale out. If it was easier, I might spend less time tuning, more time moving forward. As it is now, you need "well performing" code, but not necessarily optimum code.
June 15, 2008 at 4:43 pm
I've never known hardware to be the solution to any performance problem... not ever.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 16, 2008 at 1:30 am
Eventually, though, we're paid to produce solutions for problems. If what we produce does the job and isn't storing up obvious problems in the future, we've done what we're paid to do (i.e. what the customer wants). If we let our employer know of the trade-off between delivery schedule and future-proofing/performance tweaking, they can make an informed decision.
One of the problems I have seen all too often, though, is IT professionals putting together a technically elegant solution where a far simpler one would do just as well. In that case, the code may be "right", but the solution's wrong.
Semper in excretia, suus solum profundum variat
June 16, 2008 at 1:45 am
There is no substitute for correctly understanding the business requirements. There is no subsitute for a design that correctly implements those requirements. There is no substitute for code that correctly implements the design. There is no substitute for documentation that explains what is needed to the skill set of developers who will need to maintain the software. Doing those things right is always faster than doing them wrong, building a flawed solution, and then fixing the flaws.
That said, there are many different ways to measure software.
To name a few, we could measure based on:
Correctness of Results.
Speed of Computation.
Ease of Use.
Presentation Effectiveness.
Cost to Train.
Maintainability.
Flexibility.
Scalability.
Return on Investment - Short Term.
Return on Investment - Long Term.
Market Share.
Cost.
Time to Market.
Computer Science is the science of trading away something you want to get something you want more. No design can maximize all the above measures, we have to develop software based upon which measures are most important to the organizations paying us (within the limits of ethical and legal behavior). Doing things right means understanding the correct criteria for judging the quality of the design and its implementation.
Speed of Computation is just one measure of success and, within fairly broad parameters, often one of the easiest to get a passing grade in without a great deal of effort.
I think programmers put too much stock in this measurement. A few milliseconds faster just isn't important for most businesses for most business processes - not compared to the cost of making that happen. For those few situations where it is critical, then some other measurements will have to get lower scores in order to maximize computation speed.
June 16, 2008 at 4:00 am
david_wendelken (6/16/2008)
There is no substitute for correctly understanding the business requirements. There is no subsitute for a design that correctly implements those requirements. There is no substitute for code that correctly implements the design. There is no substitute for documentation that explains what is needed to the skill set of developers who will need to maintain the software. Doing those things right is always faster than doing them wrong, building a flawed solution, and then fixing the flaws.
Having come into Information from a construction background I have to say you're right, but the customer doesn't always see it that way. Customers want to use their new building at a given date and they would prefer you to get off site and hand it over on that date. If you have to come back and fix stuff later...
The same applies to all kinds of IT systems. You know it works (sort of) and they want it now. All you can do in that situation is tell them you know there's more work to do.
In construction the customer comes back with a list of defects. No reason they shouldn't do the same in IT.
Viewing 15 posts - 1 through 15 (of 53 total)
You must be logged in to reply to this topic. Login to reply