|
Spooner's masculine condition has reached an impasse (9)
Good luck!
You have just been Sharapova'd.
|
|
|
|
|
Stalemate?
Spoonerism of Male [masculine] and state [condition].
veni bibi saltavi
|
|
|
|
|
You are up tomorrow.
You have just been Sharapova'd.
|
|
|
|
|
It will be a pleasure to think of a clue. It may possibly be offensive to the entire country of Belgium.
veni bibi saltavi
|
|
|
|
|
They do deserve it: they named the whole country after the rudest word in the entire universe.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Prejudice[^] 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
"...and our first contestant is a hairdresser from *BANG*"
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Message Closed
modified 13-Apr-15 3:58am.
|
|
|
|
|
I heard this phrase recently and it struck a chord. As software developers we are passionate about what we do, trying to build the best solutions we can with the tools at our disposal. We try to employ good software practices through the use of design patterns, abstractions, re-usability, loose coupling etc. We try to come up with the best design we can to fit the problem at hand.
When we blindly implement whatever can of spaghetti is asked of us, then we have reached the point of software bankruptcy. Anything goes, no matter how much of a maintenance nightmare it might produce, no matter how big the ball of mud it will create.
Pressure from the business to meet a deadline is often the trigger for bankrupt software. But equally, we need to stand firm and make a stand for quality. If we fail in that task, can we really call ourselves professionals?
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: If we fail in that task, can we really call ourselves professionals
Yes, the fact that you have made the effort to inform management of the problems with building bankrupt code to meet a deadline is a professionals job, building the best application they can WITHIN the constraints of the business is also his job.
Management has different priorities to a developer and they are the ultimate authority on a decision, they hold the pay packet after all.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
If you escalate the issue (with required evidence) you'd be surprised how flexible the priorities of your management can turn out to be 
|
|
|
|
|
Duncan Edwards Jones wrote: you'd be surprised how flexible the priorities
Not if they are a half competent management team!
I got to admit I negotiate for the longest deadlines I can get them to agree to then ignore them. I find delivering reasonably elegant code generally takes less time than spaghetti anyway. I will also refactor instantly when I identify a bad design.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
If a team of civil engineers proceeded ahead and built a bridge that they knew was of insufficient quality due to its poor design and materials, and that the bridge therefore risked failing (and posing a potential risk to public safety). Do they get off the hook simply because "they were told to do so" by their paymasters?
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
You point out the risk to management and depending on your level of responsibility you make a stand, if you identify it as a public safety risk you make a stronger stand!
Most of us do not work on applications where "public safety" is an issue, I certainly don't, so it is not an argument I have ever had to consider (I sound like a weasely politician bleh).
I have refused and quit when I considered the management requirements too outrageous, but never because there was any threat to life and limb.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Ha, of course not. You know how responsibility works, right?
The Fall Guy will be selected from the bottom of the chain of command, never the top.
|
|
|
|
|
In reality there are cases when the management makes decisions (mostly not proved to be right after then) that this specific feature must be developed immediately! In such cases the only thing you can do is inform them - in written form - about all the mess it involves, then done it...But that makes you no non-professional...The fact that you see the problems points out that you are a professional...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
As professionals, we rarely have the luxury of developing a system from scratch, with reasonable schedules, etc. We must often:
- Maintain old, poorly-written code
- Write to a deadline
- Develop a silly (in our opinion) feature because "Marketing says so"
- ...
The true test of a professional is not whether he can develop the best system possible (in the Ideal sense), but whether he can:
- Spot the constraints on building the system
- Ensure that the stakeholders (Management, Marketing, clients, etc.) know of the constraints, and of their consequences
- Develop the best system possible, within the constraints
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Dominic Burford wrote: can we really call ourselves professionals?
No and never while part of the entry process is "interview questions". Name another profession which does that.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
Things going bad at work are they?
The purpose of engineering software it to put together a product and sell it.
Not all products are haute cuisine, some are burgers and chips. Doesn't make them a bad product, just a product that meets a need. So sometimes you need to stack it high and sell it cheap and your job as an engineer is to make that come about.
DO you think every mechanical engineer working on cars has the luxury of 'making a stand for quality'? Of course not. His job is to do his job and producing a cheap product is often part of that.
modified 13-Apr-15 4:43am.
|
|
|
|
|
100% agree with this as it reflects what I've seen in my career. Sometimes you get time and space to develop a good product they way you'd like - it's great when that happens. More often you're having to get stuff out fast (built on layers of existing spaghetti code) to meet promised delivery dates.
Sometimes "bankrupt development" is better than "bankrupt client/employer" 
How do you know so much about swallows? Well, you have to know these things when you're a king, you know.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote: Sometimes "bankrupt development" is better than "bankrupt client/employer"
Exactly.
In fact I quite enjoy the challenge of making a great product from crap, a bit like a chef with cheap cuts of meat. It really taxes the creativity to make the thing fly!
One of my favourite programs is scrap yard challenge, and the best episode is the US one where three teams build planes in two days, from junk. That, is engineering! 
|
|
|
|
|
I think we'll always try to do our best work, but the reality is that we have to recognise what's possible within the constraints that we have to work in (time, budget, resources, etc).
How do you know so much about swallows? Well, you have to know these things when you're a king, you know.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Munchies_Matt wrote: I quite enjoy the challenge of making a great product from crap
You are hired ! cheers, Bill
«To kill an error's as good a service, sometimes better than, establishing new truth or fact.» Charles Darwin in "Prospero's Precepts"
|
|
|
|
|
You're willing to accept the "weekly meetings about GW" item into his contract?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Munchies_Matt wrote: One of my favourite programs is scrap yard challenge, and the best episode is the US one where three teams build planes in two days, from junk. That, is engineering!
I would call it "MacGyvering". "MacGyvering" is closely related to engineering (you have to know your subject very well in order to succeed), but you would not want to rely on your local scrap yard for parts in a mass-production environment.
As I see it, engineering is the discipline of using established methods to design and build devices in a reliable manner. For mechanical devices, part of reliability in this context is the reliability of the supply chain required to build them. In the commercial world, it is of little use to design the "perfect device" if building it is impractical.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
