|
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
|
|
|
|
|
It's from apple, innit?
iWork, iJustwork, iBarelywork -- sumfin' like that.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Smart work is the reason you give for playing solitaire when your colleagues ask WTF you're doing.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
"Compiling!"
Obligatory XKCD[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I know! I know!
The answer is "Cheese"!
Because:
- Hard work & smart work
- Hard talk & smart talk
- Hard @rse & smart @rse
- Hard cheese & smart ???
I'm really good at these!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: The answer is "Cheese"!
Because:
I'm really good at these!
..basically?
|
|
|
|
|
I had a book of puzzles, once!
Green, it was.*
* Several kudoses for whoever gets the reference
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: The answer is "Cheese"!
Wrong! The answer is "Core".
You have just been Sharapova'd.
|
|
|
|
|
Nah - that's only 4 letters...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Actually, it's probably a safe bet that some chip manufacturer, somewhere, has named one of their chips "smart core".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
