June 16, 2008 at 4:40 am
tim.pinder (6/16/2008)
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.
In the perfectly valid example above, the customer has chosen to value Time to Market over other criteria, such as Correctness of Results. Ease of Use, etc.
As long as we clearly let them know what the trade-off would be, and they agree, then all is well.
If we let them know what the trade-off will be and they don't like it, too bad for them. 😀 We've done our job responsibly (assuming we've done the other parts of the project responsibly, of course. 😉 They can pick a different mix of criteria to maximize, and we can tell them which value components of the system will be reduced as a result.
The customer should not be surprised. They should know ahead of time.
June 16, 2008 at 6:11 am
"If we let our employer know of the trade-off between delivery schedule and future-proofing/performance tweaking, they can make an informed decision."
I've found that that usually takes more time than just doing it right.
"Computer Science is the science of trading away something you want to get something you want more."
Where in the heck did you get such a definition? That's not what computer science is at all. That may be your perception, but it's not computer science.
"As long as we clearly let them know what the trade-off would be, and they agree, then all is well. "
Heh... yep... that's what crack dealers tell their customers.
C'mon folks... I'm not talking about shaving an extra second off a 10 million row batch... but I am talking about getting a 10 million row batch to run in something less than the 8 hours that I've seen some code do. And time to market should never be a problem... put more good people on the project. If you don't have those people, then you've overstated your abilities in the bidding process and need to be punished. 😉
Whether the customer says so or not, time to market should never be an excuse for crap code.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 16, 2008 at 6:30 am
And time to market should never be a problem... put more good people on the project. If you don't have those people, then you've overstated your abilities in the bidding process and need to be punished. 😉
Whether the customer says so or not, time to market should never be an excuse for crap code.
This is how the 'cheap' outsourcers (and some expensive consultancies I cannot mention) work. They tell you they can write your apps quicker and cheaper and it will be ready by such and such a date, and it is, but they never promised it would work, that's phase 2. This is 'tick in the box' methodology, code written, task done, payment accepted, move on.
Also, every project should have a warranty period, where the people who supplied the code support it in production for the first few months. (with the assistance of the DBA, but its their responsibility) Much better than throwing it over the wall, running like hell and blaming the DBA\database\hardware for problems.
---------------------------------------------------------------------
June 16, 2008 at 6:56 am
I think you're all saying basically the same things, you need your software to be 'directionally correct', as the finance folks at my organization like to say. If it doesn't function, or is in danger of imminent collapse, then it's not 'correct', direction be damned.
If what you have done during the timeframe allotted performs the necessary functions in a stable manner, but isn't as pretty as you can possibly make it, then go with efficient. IMHO, if it's going to break in the first strong wind, then it's not completed.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
June 16, 2008 at 7:03 am
george sibbald (6/16/2008)
This is how the 'cheap' outsourcers (and some expensive consultancies I cannot mention) work. They tell you they can write your apps quicker and cheaper and it will be ready by such and such a date, and it is, but they never promised it would work, that's phase 2. This is 'tick in the box' methodology, code written, task done, payment accepted, move on.
Notice that I said to put more "good people" on it... I never said that cheap outsourcers were the place to go... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
June 16, 2008 at 7:06 am
jcrawf02 (6/16/2008)
IMHO, if it's going to break in the first strong wind, then it's not completed.
That's more like it and that's part of what I'm talking about...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 16, 2008 at 7:17 am
I wonder if we're arguing semantics. Does Steve mean within 10-20% of the *functionality* or 10%-20% of the *utopian ideal* functionality?
If the first, then I most strongly *disagree*. If the latter then I can somewhat agree, depending of course on whether "good enough" really is "good enough".
I am most fortunate in being the only IT person in our company. While it means I do everything from database design to replacing broken mice it also means I have a great deal of development freedom--which saves my sanity since in my company's industry business requirements have all the stability of a psychotic pinball machine.
In my experience the rule is "You can take the time to do it right--or do it over. And over. And *over*."
From the beginning I've fought for "general case" solutions, never "solve this one problem and move on". Yes, it takes much longer. But when the rules change the code is usually flexible enough it doesn't need to change too.
Every time I've been forced to break that rule it's come back to bite me--usually in less than a year. Over time those at the top have come to appreciate that cutting corners in IT is a lot like shaving with a straight-razor while driving in an off-road race.
Another way to say the same thing is "Fast, cheap, and good--choose any two."
So, Steve, which do you mean? Shaving a milli-second off a half-second run? Or turning an 8-hour run into a 30 second one? 🙂
June 16, 2008 at 7:29 am
You also have to be working somewhere that will allow you to be effective, instead of mindlessly working with the "technical" specifications handed to you from on high. Where I currently work, I fought the good fight a few times on my last project with my manager and won, only to be given the cold shoulder ever since. I had to do it to get the project in on time and working correctly.
Another project running at the same time didn't have people with the same amount of assertiveness (and a harsher project manager who liked to come up with elaborate Rube-Goldbergian solutions to simple problems). They are STILL working out the bugs, 6 months later.
I'm happy to say that I'm leaving this job in a week for one where the folks seem laid back and like to brainstorm ideas in order to come up with the right ones.
June 16, 2008 at 7:31 am
My frustration comes when the developers rush a project out the door so they can say it went on time and then move on to the next project. It doesn't seem to mater if the DBAs object to how the project is being written. Meantime, I as a DBA have to support the project. It seems anytime there is an issue it is always a "database" problem. So I spend the next several hours determining that it is not a database problem.
I wish the management would listen to the DBAs a little more to what is acceptable database standards and stop letting the developers do whatever they want with a database they they will not have support.
June 16, 2008 at 7:42 am
Please note that "Time to Market" is a short-term goal. Doing the same thing over and over is long term, and should not be a goal at all, because it drains the company of resources (both $$ and personnel) that could better be utilized elsewhere.
And what a customer (internal or external) "should" understand is very different from what they remember 3 months down the road when you don't have time to work on "their" software failure because you are working on someone elses for the fifth time. (So get that "time to market" stuff in writing, and make them sign it!)
If I'm told to do something "wrong", like put up half-baked code to get something in "on time", I'll object 3 times with details about the cost later on down the road. If managment still insists, then I'll do it - they are the ones that make the business decisions. However, I draw the line at creating "shells" - things that look like they work, but don't do anything - that's not ethical in my view (and that's different than a prototype for discussion, by the way).
Code utopia is definitely not the goal. Well-written code that works, meets the business need, needs no maintenance until business needs change, is well documented, and is scalable IS the goal, IMHO.
Poorly written code is like a dead albatross around a company's neck - it will drag them down to oblivion unless it is removed - which takes more money and time than doing it right would have! Very often, "time to market" is another word for "client managers don't know how to manage expectations" - they promise what WE can't deliver without discussing it with anyone, then they act like it's the end of the world when we tell them the reality (and try to make it IT's fault when the goods are delivered late). A good client manager checks first, and when the specs change (as they always do) is able to explain the additional cost/time to the client. That IS their job, after all.
Steph Brown
June 16, 2008 at 8:09 am
I have to agree with Steve, but I want to agree with Jeff!
We are often asked to work on something as "Priority One!". This usually means you do not have the time to think the solution through thoroughly, let alone program. They always want something done as quick as possible because the client is "very unhappy". Um, I wasn't the one that promised the world to the client, you were, Dillweed (source: Jeff)!
What I don't get is why any client would ever be happy with what I refer to as "Walmart programming". Oh, let's program something fast and cheap and when we take it home, it will probably break! What a great deal! Remove your head from your heiny, please!
When I am asked for an estimate on how long something will take to program, I do what Scotty in Star Trek does. I estimate how long I feel it will take and multiply it times two. This lends the opportunity to get it done before expectations, but also a do it right in the first place. I take issue with someone that doesn't program telling me how to program, or trying to put a time limit on me. Managers should not be estimating time for program completion or promising anything except an exceptional application that fits the clients requirements and is error resistant.
I actually had a manager tell me on one occasion that the project did not require any error handling. "Let's just get it to the client as fast as possible to make them happy, we can come back later if there are any problems." GASP! I pretended to agree with said dill-hole and programmed it the right way anyway. I probably saved him from losing his job, so it was counter productive on my end. Drat!
If a doctor only ran one blood test on you and sent you home instead of running a series of tests to get the best collection of data to properly diagnose you, there would be a problem.
We, as programmers, must think outside of the box and program as efficiently as possible taking all possible scenarios into thought. Program it, then try to break it. If it breaks, reprogram it. Then send it to someone else to try to break it. If it doesn't break, don't fix it. It is now ready for the client.
Do I want to be right? No, I have to be right! I can't depend on anyone else to do the right thing!
June 16, 2008 at 8:34 am
Great points and this is an interesting debate. But it's not black and white.
Functionality has to be 100%. Or what the client needs the software to accomplish. Performance/speed/whatever we measure, could be less.
There's a huge difference between turning a 10M row batch from an 8 hour run into a 8 minute run. But if you make it run in 45 minutes quickly is that good enough? Maybe you think you can do more or even see more tweaks, but they take time. How much time to do you spend?
If you build something in prototype fashion, it runs well at first, and you decide you need to use much of this code because of time. Perhaps you tweak things as you move forward and you know that you can get better performance if you rewrite it, but time is a factor. What do you do? It depends.
If you don't like the code, think it could be better structured, or designed, or you'd like to make it an extensible platform, you might need to delay those decisions since they eat up time.
It may be a technical debt you're incurring, but it might not. Circumstances often change and what is a great decision for the future today might not be in a year.
The other thing is that I have seen hardware help. If I have something that's performing so-so on a 2x2 (2 CPU, 2GB) box, I've covered issues by moving to a 24 or 4x4. I've also scaled out with data archived to a second box or by replicating some data to another box for read-only queries. It's saved lots of time, and made it possible to continue to develop new features while adding more clients. I'll admit the latter was a technical debt that had to be tackled later, but it was delayed.
As my CPA says, defer that debt as long as you can.
June 16, 2008 at 9:12 am
Steve Jones - Editor (6/16/2008)
Great points and this is an interesting debate. But it's not black and white.Functionality has to be 100%. Or what the client needs the software to accomplish. Performance/speed/whatever we measure, could be less.
There's a huge difference between turning a 10M row batch from an 8 hour run into a 8 minute run. But if you make it run in 45 minutes quickly is that good enough? Maybe you think you can do more or even see more tweaks, but they take time. How much time to do you spend?
I think it comes down to what is good enough. Where is the line of acceptability drawn? It's not going to be in the same place every time for every system.
Say an airplane's navigation system. That must not give an incorrect result. If, however, the HR dept's leave system fails to calculate available leave once every 10000 times it's used, it's not quite so critical.
On a performance side, spending a couple hours on getting the batch job to 8 min is time well spent. What about spending another 16 hours to get it down to 5 min? Effective usage of resources?
I'm not suggesting writing bad code, or been lazy, or leaving stuff half done so it crashes in a week. That's far below any bar of acceptability and should not be tolerated.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 16, 2008 at 9:19 am
put more good people on the project. If you don't have those people, then you've overstated your abilities in the bidding process and need to be punished.
I am a good developer. I have written elegant, maintainable, documented code for a poorly designed, spagetti coded system that should have been rewritten before I even had to help support it. I equate that system (though not in dollar value) to FedEx. It does what the users want, and has been extended to support things the original developers never even thought of doing. My college course work prepared me for working in a 3GL environment.
When it comes to SQL, I am still a good developer, but everything I have learned about SQL, I have learned on the job. Code I wrote 10 years, 6 years ago, did the job it was required to do and did it well. In the last few years, however, I have learned quite a few new things regarding SQL, and looking back at things I had written, I now know new and better ways to do things. Again, does that mean the things I wrote earlier are now wrong?
If speed is significant factor in a process, then they should know that it may take more time to find the correct solution. Not all of us have had the opportunity to be in an environment where we needed to come up with a solution to reduce an 8 hour process into a 30 second (or 8 minute) process. So we may not have some of the knowledge that Jeff does in writing highly performant code that he has. Does that me we aren't as good? I'd like to think that if given the time, I'd be able to figure out a better solution for such a problem as well. Jeff may be able to do it quicker, with experience, so could I.
😎
June 16, 2008 at 9:33 am
Your job is to build three chairs. You build the first chair and while you are building it you realize that you could have done it better. So in the mode of perfection you destroy the first chair and rebuild it again.
As you near completion of the chair you find out that there is new technology in chair building and your chair is now out-of-date. Not to deliver a 'half-baked' old technology chair you cast off the first char for a newer model. While you are building the new 'fist char' in the new technology you again realize that you are not using the new technology as well as you need to.
Again with the 'lessons learned' you rebuild the 'first chair' for the n-th time. Now it is perfect and you have your first perfect chair and only two more to build. You congratulate yourself that you have built only four chairs to build one.
At this point you are fired!
You tell the boss that you built the perfect chair and that the other three you threw away were not good enough for you.
He tells you that the three you tossed were what the client wanted, three solid chairs people could use at a reasonable price. And further if it took you four attempts to build your perfect chair then it would take at least 12 chairs to build three, and the company could not afford your 'perfect solution'.
And by the way after all this 'perfection' stuff, many bosses would doubt that you could get the job done at all.
Part of the perfect solution is that it is done at a price the user will pay, and done within a timeframe with solid deliverable dates. If you can not do 'perfect' within those parms, you get to go somewhere else and work.
Not all gray hairs are Dinosaurs!
Viewing 15 posts - 16 through 30 (of 53 total)
You must be logged in to reply to this topic. Login to reply