|
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
|
|
|
|
|
I don't like this concept of "software bankruptcy:" to me it smacks of some kind of "moral absolutism" that locates the definition of "professional" in refusing to compromise rather than "embodying" and "performing" your science/art/skill/craft to a high-standard of excellence.
I find this painted with "too broad a brush," mixing ideals with values, and I think most real-world scenarios where issues of identity and values arise are not so "binary;" for example:
- I am part of a team working on software that protects lives: if I silently agree with a design decision I am certain will endanger people, because it's inherently flawed: that's a truly moral/spiritual dilemma that transcends my "professional" identity.
Sound clear-cut ? Easy decision: you "blow the whistle" to the media ? Is your last name "Snowden" ?
Now consider that the scenario has the following aspects:
- there is no issue of "criminal negligence" here, and projections of casualty/injury over time are statistically sound.
- the "better design decision" would add four months to shipping the software; during that four months a certain number of people would definitely not die, or be injured, because the software shipped four month earlier.
Okay, you can (legitimately) argue that the "spotlight of life-or-death" puts everything in a different, urgent, critical, light here. And, s'truth that most real-world dilemmas are much more mundane; like:
- Bozo/Bozetta the new Manager, attempting to "make their mark" and hop on the fast-track to success demands a "killer" new feature, that a programmer skunked-work into existence, be shipped before it is regression tested. There's a strong possibility that said new feature will break previous versions of the application in a variety of ways, as well as cause frequent crashes.
- if you, programmer, quit now, you will lose substantial stock-options that have not yet vested, and those options coming on-line are essential to you and your family's plans to buy a house
- other member of the programming team are not upset about this decision: but you ... are.
What now ?
“We are what we repeatedly do. Excellence ("Arete"), then, is not an act, but a habit.” Aristotle
«To kill an error's as good a service, sometimes better than, establishing new truth or fact.» Charles Darwin in "Prospero's Precepts"
|
|
|
|
|
I don't particularly like the term either, but then I didn't coin it. The term (while being quite contentious and controversial if the posts on here are a measure of that) describes quite well what it refers to.
What one developer considers to be a bankrupt decision is entirely subjective and will vary from person to person. Everyone has a different appetite and tolerance level so there cannot be any "absolutes".
"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: The term ... describes quite well what it refers to
The entire point of my post is that the term is not valuable in a distinct way, and that its blurred semiotic overlapping of the cultural connotations associated with an extreme state/event (bankruptcy) with software development is not useful.
However, perhaps the term has "redeemed itself" in this thread by provoking an interesting discussion of what "professional" means for programmers, and to what (if any) extent "social/moral responsibility" comes into play ... not to mention possible civil/criminal liability under certain interesting circumstances.
«To kill an error's as good a service, sometimes better than, establishing new truth or fact.» Charles Darwin in "Prospero's Precepts"
|
|
|
|
|
Quote: However, perhaps the term has "redeemed itself" in this thread by provoking an interesting discussion of what "professional" means for programmers, and to what (if any) extent "social/moral responsibility" comes into play ... not to mention possible civil/criminal liability under certain interesting circumstances.
If I have initiated a discussion and debate on the issue then my work here is done as that's all I ever intended
"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: What one developer considers to be a bankrupt decision is entirely subjective and will vary from person to person. Everyone has a different appetite and tolerance level so there cannot be any "absolutes".
Therefore all development is bankrupt, in the eyes of one or many people, and therefore the term is worthless.
My work ethic has always been "do your work to the best of your abilities", not "blame everything bad on someone else, because they don't meet my standards", which is the direction the bankrupt-development thing pushes into.
The primary consideration for any product should always be "is the customer happy?*", not "does it meet my personal preferences in coding style", which might as well be "does it meet with the intolerance requirements of my religion?"
It's really easy to lay down rules for everyone else to follow -- it must be easy, because everyone seems to do it -- but the point is that there is always someone who has to lay down the rules, and if individuals decide unilaterally not to follow them, they they become a problem.
If you've got to write code that peeps a little noise when a disposable lighter is nearly empty, the rules will be: just hack something that works.
If you have to write code to handle income taxes for a government, you follow the rules that are issued to you in a very thick rule book.
The only times you, as an individual developer, can get involved in setting the rules are:
- If you're working on a private project on your own time.
- If you head the company/department.
- If it's an agile shop.
There are times when "Ours not to reason why..." is worth keeping in mind. Every decision cannot be made by every person who works on a product.
* And remember that your manager is also your customer, who is paying you for a service.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Wrong forum.
Put it on your blog.
|
|
|
|
|
Quote: discussing anything in a software developer's life that takes your fancy
I think the Lounge is exactly the right forum.
"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
|
|
|
|
|
I'm curious what your definition of "Bankrupt Development" is. I read an article a while back and I'm thinking that it's what your talking about but other posts here aren't quite jiving with what I have read.
To me, bankrupt development is like this. You have a project and you're behind on your deadline so you cut a few corners and put out a less than excellent product in order to get things done on time. This concept has it's place. Sometimes it needs to be done. The bankruptcy concept kind of comes in later, from what I understand. You've put out this lesser quality product and it's going to need patching as users find the errors. It's like you've taken out a loan. Your programmers have not had to work as many hours making the big product, but you're going to need to have them work after to fix up issues, or make "loan payments". If you don't make time for your programmers to do this you have defaulted on your "loan".
If you do this once...fine. It happens. But if you continually do this your company is going to be known for poor quality and there will be consequences down the road. And that could mean for reals bankruptcy.
I think this is definitely a problem today. I think it's a little bit about managers not realizing how the development process is really supposed to work. Not realizing that it actually takes more work (the interest) to fix problems later when a product has been deployed than to do it right the first time.
|
|
|
|
|
What you're referring to is technical debt which can be perfectly acceptable as long as sufficient time is afforded to repaying the debt afterwards.
What I was really referring to were serious errors of judgement that would question one's integrity and / or professionalism. For example knowingly implementing a feature that could prove financially costly in the long term to the business. A feature that could harm the brand or in the worst case put safety at risk. I gave the fictitious example of a team of civil engineers who build a bridge knowing that due to the faulty design or poor quality materials it may put safety at risk.
At what point does a developer make a stand?
"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
|
|
|
|
|
Yikes. Okay. Way more serious then.
It makes me think of installing java. That stupid checkbox for installing that stupid piece of crap toolbar is always defaulted to checked, and you have to remember to uncheck it. Yeah. The programmer that did that should definitely be ashamed.
|
|
|
|
|
Damn right he ought to be ashamed 
"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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
