|
Design Skills are Worthless.
Portion of the code:
(1) Server-Side - generates a long return text value which contains the content of some query. Doesn't package the data into XML! Comma delimited. (And mind you, there are PLENTY of 'Smith, John' type values.
(2) Client-Side - accepts the SOAP call text value... Apparently couldn't figure out a way to parse the data, so he writes it to a file on the hard-drive so he can use some kind of readword() method somebody wrote by hand.
(3) Apparently doesn't quite grasp the idea of 'class' or 'struct', so he has like twenty arrays like name[], id[], date[], ... Then, as he's populating the arrays, he resizes them all with every iteration.
(4) Deletes the file.
(5) Then, it seems he realized he had to do something similar to the same list, so instead of inserting some code into the loop, he cuts and pastes the code for steps (2)-(4) into the same routine, and does everything over again!
This guy is a hero here, though, because he gets everything done quickly. While idiots like me put a little though into the design of class libraries, this goober is the guru.
Seriously, is there any value nowadays in working on design skills? Have they ever benefited anyone? Management can't see them when they're running the app.
anon
Thursday, May 13, 2004
"Management can't see them when they're running the app."
And management also won't see it when the entire app has to be re-written when it needs to scale beyond it's current capabilities.
And when you struggle with redesigning a pile of steaming dung, they will bring in the Goober Guru to save the day.
Oh..you were wanting good news weren't you? Sorry.
Whatever
Thursday, May 13, 2004
The bigger problem with this is that it can hurt the company in the long run.
Building diffucult to maintain or change systems paralizes a company when they have to change their business model slightly or alter a business process. Because then it turns into a "big IT project".
The business management doesn't know how long it should take or that the systems are being designed poorly.
But it can eat away at the company. Over time as these crappy systems (large or small) are created you could end up in a situation that would cost the company tons more money in resources and time (time is money).
That is why it is very important for the IT department to have a management staff that understands the basics of software design, and can communicate to the business units why IT needs extra time up front to "do it right the first time". Hopefully the IT department also also has people who can design correctly. (Not to mention work in a technology that interoperates with other technologies easily, so you're not stuck with 1 vendor's stuff.)
Am I making sense??? Or have I gone all lunny?
michael sica (michaelsica.com)
Thursday, May 13, 2004
Yes there's value in them, but without management buy-in you're just going to be killing yourself if you think that you can 'covertly' win them over. If you explain the long-term implications of overly verbose and informally codified institutional knowledge to them, and they still don't care, find some place else to work. Some people just want somebody who'll be there to put out fires rather than designing fireproof systems, and if that's not what you want to do then you ought to reconsider being where you are.
It's also true that some problems don't require grand architectures. The long-term cost of using a cheap and ready Rube Goldberg device over a more expensive and minimally complicated one is not always obvious. Some managers will tell you that coming up with a fancy design for the problem of generating a report that might not even be relevant in a few months is gilding the lilly's mulch. And they'd be right.
But if you stop right there with your analysis, you're missing the larger issue. If a programmer's not capable of doing the long-term grand designs, then he won't be able to see where it's necessary (and management ought to be aware of that particular liability).
The success of a project rides largely on doing a beautiful job where it counts.
Kalani
Thursday, May 13, 2004
"is gilding the lilly's mulch."
If I don't learn anything else today, I'm gonna be happy that I've added that phrase to my vernacular.
Whatever
Thursday, May 13, 2004
Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.
-- Alan Perlis
_
Thursday, May 13, 2004
Tell them:
I can be a construction worker or a fire extinguisher for you. Now you can either let me rebuild your straw house as brick to withstand the fires -- knowing full well that brick will cost more up front. Or I can continue working with your straw house and you'll have to hire more fire extinguishers (developers) in the coming months to put out the fires fast enough you don't lose the whole house.
You decide whether you want to spend money on a fire brigade every few months forever, or a skilled architect once.
Andrew Hurst
Thursday, May 13, 2004
WTF is that supposed to mean!? Seriously...<shakes head>
Anon-y-mous Cow-ard
Thursday, May 13, 2004
Probably a bad metaphor. What I meant:
straw house == hacked together, brittle system
brick house == system designed to be easy to maintain
Fires might be changes in the business process, or bugs found later. With the hacked together, badly designed (or not designed at all) system any small bugs and changes will be huge and hard to fix. Think about how out of control a small fire on a straw house would get.
With the brick house, it could handle the fires easily because it was designed to. i.e. the program is designed to be easy to change and maintain, so when something comes up that requires change, its no problem.
Thus you need less firefighters -- maintenance programmers -- in the long run because each fire is smaller. You could have just one guy with a garden hose instead of 4 fire trucks full of developers.
Andrew Hurst
Thursday, May 13, 2004
"The bigger problem with this is that it can hurt the company in the long run."
The biggest company is that the company doesn't care.
When the "long run" problem hits, everyone just pushes 60-, 70-, 80-, whatever-hour weeks, and everything's fine and dandy.
Why should mgmt care about proper design?
Paulo Caetano
Thursday, May 13, 2004
>>WTF is that supposed to mean!? Seriously...<shakes head>
Sorry, I was talking about this f***ing idiot...
>>Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.
-- Alan Perlis
Anon-y-mous Cow-ard
Thursday, May 13, 2004
"You decide whether you want to spend money on a fire brigade every few months forever, or a skilled architect once."
Well, based on my experience and those of my friends "Firebrigade" scores an almost perfect 100%.
Just me (Sir to you)
Thursday, May 13, 2004
Nope, good metaphor, Andrew. Now if only management could get a clue...
Rorschach
Thursday, May 13, 2004
Actually it sounds like you're bitching about implementation nuances rather than design. The design is that it grabs the data in some interpretable/transportable format using SOAP, interprets it into data structures, and stuffs it somewhere else. Whether the individual functions have copy pasted code, don't follow the variable naming standards, or are buggy and spaghetti-like, is primarily an implementation detail - most of what you've mentioned can be very easily refactored. The data encapsulation perhaps is less than ideal (though encapsulating a CSV is entirely valid and isn't in and of itself an implementation flaw) and isn't as maleable, but it really isn't a big deal.
Dennis Forbes
Thursday, May 13, 2004
>With the brick house, it could handle the fires easily
>because it was designed to. i.e. the program is designed
>to be easy to change and maintain, so when something
>comes up that requires change, its no problem.
Not that I disagree with the intent of your message Andrew, but I think that a straw house would actually be easier to change while a brick house would be easier to maintain. With a straw house, the costs of taking down a wall and putting up some new ones is pretty low, but you've got to put out fires and sweep up straw all the time. The brick house buys you reliability, if not at the cost of some rigidity.
Thursday, May 13, 2004
Design skills aren't at all worthless, but they are overrated by a certain percentage of developers and sometimes used by some as a procrastination tactic against getting down and dirty with code, IMO.
Don't get me wrong, good design is important, but I've worked on a few projects that were run by design nazis that couldn't contain their "what if we added or supported this..." compulsions and we wound up with monster designs that collapsed under their own weight.
"Wouldn't it be cool if this application ran on the PC, the Mac, any UNIX system, PDAs and cellphones?"
Yeah, that'd be cool, man; but it would be even cooler if we just focused on rational business objectives and actually release something before the company goes out of business.
Mr Fancypants
Thursday, May 13, 2004
"You decide whether you want to spend money on a fire brigade every few months forever, or a skilled architect once."
Would this be in the imaginary world where requirements are static, technology stays still, and clarity is absolute? Architecture is very important, but it needs to be considered in a real world context.
As an aside, I once implemented an application that was a total POS from a coding perspective - tonnes of copy pasted code, adhoc design that was hashed together spur of the moment on a need basis, no standards, thousands of compiler warnings. It was intended as a prototype (actually as a personal job-aid) developed around a nebulous need and with vastly shifting requirements. As is legendary, it soon became production code, and for the years with that firm I had this travesty hanging over my head. I will never apologize for it, though, and I find it laughable when people yap about it "costing more" in the long run - this app paid for itself hundreds of times over, and anyone who could "design it right" was free to replace it (especially given that the process was heavily defined and solidified by then).
Dennis Forbes
Thursday, May 13, 2004
SOAP's an implementation detail too Dennis.
Anyway, some people would say that the only implementation is what happens when the processor does its work, and that all programming is design. You're probably one of those people if you think that the material that a bridge is built with (or at least a declaration of the set of acceptable materials) is a part of its design.
Thursday, May 13, 2004
"This guy is a hero here, though, because he gets everything done quickly. "
I think this explains it. If the respected code jockey spends a lot of design, he's a useless architectural astronaut. If he spends a lot of time making clean code, he spends too much time gilding the lily mulch. If he spends a lot of time writing productive code, he's a hack that doesn't spend enough time designing and implementing perfect designs. One great thing about being hidden in the shadows is that you can shift what you espouse to be important to contradict whatever the hero proclaims.
And if all of that fails, just bring up the generally unjustified 'scalability' comment (which is the number one bullshit comment used to denegrate code. The speaker usually can't quantify it with metrics or solid reasoning, but it's easy to say)
.
Thursday, May 13, 2004
Dot, do you think that the same amount of effort and concentration should be spent on design/implementation regardless of the importance of the software to the people for whom it's being written?
Ask a manager which of two functionally identical programs he prefers and he'll pick the one that's made faster. Ask a programmer and he'll pick the one that's least verbose. Sometimes these preferences are in alignment, and other times they're not.
So if you want a rough quantitative measure of the goodness of a program, I'd venture to guess that it's something like:
ScoreX = Sum(ETA(P, Mi) / ATA(P))
ScoreY = Sum(EPL(P, Di) / APL(P))
Where ETA(w, x) is the time that manager x estimates project w will take, and ATA(w) is the actual time that it takes to deliver w, EPL(w, x) is the estimated program length by programmer x for program w, and APL(w) is the actual program length. Mi is manager i, Di is developer i, and the absolute score is computed as the length of the 'score vector'.
This rule says that importance will tend toward the manager's ideal where there are lots of managers or where managers and developers are in equal balance and managers have unrealistic expectations. It will tend toward the developers where there are lots of developers or the developers have unrealistic expectations about optimal program length (which Chaitin showed is impossible to know for sure). If a problem tends too much in either direction there will be problems.
Thursday, May 13, 2004
There's nothing wrong with throwing something together that works, as long as, after it works, you go back and clean up afterwords. You may not like the Extreme Programming stuff in general, but in my experience the "Once and Only Once" (Or "Don't Repeat Yourself") principle DEFINATELY results in better code, even if it's just hacked together to begin with.
So Mr. Hero's only doing half the job. He got it running; now he's got to go back and make it clean. That'll pay off the second he tries to do something new with the code.
Chris Tavares
Thursday, May 13, 2004
If this guy is as bad as you claim, how come you can't do a better job? If his libraries are so terrible, why not use different ones?
Matt
Thursday, May 13, 2004
I think the answer to the question of lots of design versus hacking it together needs to be guided by the type of software being developed. Is this a software system that's used in-house for one small project, and is only going to be used for three months? Or is this a flagship shrink-wrap application that will be enhanced for the next five to ten years, that the company is betting on for its livelihood?
Sometimes it does make sense to "hack something together," if the exepected lifetime of the application is very short.
Of course, I've spent every day for the last three years working on a flagship application with a five- to ten-year lifespan, so I'm strongly biased towards stronger design. We spend only about 20% of our time coding--the rest is spent creating requirements and detailed design.
(We've gone down the "let's do less design up front" path in years past, and it was a disaster. Rewrite after rewrite. What a mess.)
Just my $0.02.
Dave
Dave
Thursday, May 13, 2004
We've struck a good balance: Our design stage streamlines our programming stage and makes our maintenance cycles a breeze. We don't spend so much time on design that the delivery time suffers.
It's a happy medium: most of the time we deliver our stuff when it's expected and some of the time we're even early. That never happened before we had a design stage.
IMO, coding first and going back to document the system later NEVER works. Assuming of course that anybody actually goes back to document the application, nobody can really remember what they did, and the docs become stilted and useless.
At least if you create design documents first, the app is built based on those design docs, which means that they had to be at least decent enough to be interpreted by a developer and produce a working application.
max
Thursday, May 13, 2004
"The bigger problem with this is that it can hurt the company in the long run."
Company...Long-Run? Will that help the stock in the short-run?
m
Friday, May 14, 2004
You have to be careful here. His code may not be designed the way you like, but that's not the most important question. That question is -- "Is it stable and does it work consistently?"(ok two questions).
If not, then the bad design will come shining through soon enough. If it does...well, perhaps you should reconsider your position here.
Crimson
Friday, May 14, 2004
Sounds like he's taking advantage of the Worse-is-Better principle. (Why aren't you?)
WIB
Saturday, May 15, 2004
(Devil's advocate) He gets working code delivered on time. Do you?
Bella
Thursday, May 20, 2004
 Recent Topics
Fog Creek Home
|
