|
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
|
|
|
|
|
which is more effective...
|
|
|
|
|
If you don't know, then I'm not going to tell you
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
If you hadn't done a lot of hard-work you will never be able to do it smart!
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I smartly avoid the hardwork of answering this question.
You have just been Sharapova'd.
|
|
|
|
|
|
What happens when?
Hardwork == Smartwork
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
"Hard work" is what real people do.
"Smart work" is what morons blather on about at expensive and useless management retreats in smart golfing hotels.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hoi can I get me some of this smart work stuff, I just seem to be slaving over a keyboard!
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
