Coding Horror

Buford T Justice · 04-05-2019 7:05pm

Would the following be considered a "Coding Horror"

public void setFirstName(String firstName){
	  
	  if(firstName.length() < 5){
		 
		  throw new IllegalArgumentException("NAME LENGTH IS TOO SHORT! ");
	  }
	  this.firstName = firstName;
  }

Depends if you're handling the exception or allowing it to bubble up and blow the app up really.....

GreeBo · 05-05-2019 7:51am

Sephiroth_dude wrote: »

Would the following be considered a "Coding Horror"

public void setFirstName(String firstName){
	  
	  if(firstName.length() < 5){
		 
		  throw new IllegalArgumentException("NAME LENGTH IS TOO SHORT! ");
	  }
	  this.firstName = firstName;
  }

It really depends on what sort of code you are writing.
If its part of a gui app then above is fine, you'll have a handler for these situations and display an error to the user, since there is nothing that can be done in code to handle the error.

If it's a shared component then I'd probably either add a throws to the signature or create my own exception class and again add the throws. It wouldn't be obvious that calling set on a pojo could explode since, typically, validation would be done earlier in the flow.

smacl · 06-05-2019 11:37am

Sephiroth_dude wrote: »

Would the following be considered a "Coding Horror"

public void setFirstName(String firstName){
	  
	  if(firstName.length() < 5){
		 
		  throw new IllegalArgumentException("NAME LENGTH IS TOO SHORT! ");
	  }
	  this.firstName = firstName;
  }

A lot of Microsoft framework code in MFC does this kind of thing, though personally I avoid it where possible as the stack unwinds can cause a serious performance hit. I don't like the idea of exceptions for bad parameters but would use them at times to cancel out of very deeply nested code where the user hits a cancel button. Pressing the cancel button is a valid exception in this case as it is not the normal flow of events and the stack unwind is desirable. In this case, I place my try..catch blocks just below UI loop / main controller level such that the exception leaves me in a good default place to be. This depends on RAII to clean up via stack unwind, which won't always be the case, so memory and other resource leaks can arise.

DublinWriter · 08-05-2019 11:58am

GreeBo wrote: »

If its part of a gui app then above is fine...

No, it's gick. PLUS it's not even trimming the white spaces out of the right side of the string. PLUS the exception isn't stating specifically if the first or surname is too short.

cython · 07-06-2019 9:48am

Several hundred log statements along the lines of the below added in the last few days:

logger.error("ClassName.methodName started");
//Do some stuff
logger.error("ClassName.methodName completed");

Yup, debug/trace log messages being logged with severity of error. :mad:

smacl · 07-06-2019 11:18am

cython wrote: »
Several hundred log statements along the lines of the below added in the last few days:
logger.error("ClassName.methodName started");
//Do some stuff
logger.error("ClassName.methodName completed");
Yup, debug/trace log messages being logged with severity of error. :mad:

And your coding horror shows up a bug in boards. You wrote

Chrome shows

Nested coding horrors :pac:

07-06-2019 11:35am

smacl wrote: »

Nested coding horrors :pac:

Bugception

cython · 07-06-2019 8:53pm

smacl wrote: »

And your coding horror shows up a bug in boards. You wrote

Chrome shows

Nested coding horrors :pac:

And there I thought it was just my browser being an ass. Was also too f*cked off to dig further after finding that steaming pile of horse manure!

pillphil · 07-06-2019 9:00pm

Weird, it displays fine in my chrome browser on mint, but on mobile the original text looks wrong and the quote displays fine.

Edit: Removed massive image

pillphil · 07-06-2019 9:06pm

Ha, it's an advertising thing, skimlinks, it reads the something dot something and tries to create a link. which ****s up the display

johnmcdnl · 18-07-2019 10:22am

public class RandomGenerator {
  public static String generateRandomString(int numberOfCharacters) {
    String newStr = "";
    for (int i = 1; i < numberOfCharacters; i++) {
      int numericValue = (int)Math.round((Math.random() * 61.0) + 1.0);
      if (numericValue > 52) {
        numericValue = (0x2F + numericValue) - 52;
      } else if (numericValue > 26) {
        numericValue = (0x60 + numericValue) - 26;
      } else {
        numericValue = 0x40 + numericValue;
      }
      newStr += (char)numericValue;
    }
    return newStr;
  }

It's really old legacy code, that is far away from the critical path, so fine maybe back in the 00s there wasn't any easier way to generate a random string than rolling your own?

1) But why would you use hexadecimal in the addition of the numbers -- because who can't read hexadecimal right?
2) And why does the returned string have length 1 less than 'numberOfCharacters' -- generateRandomString(4) returns a 3 letter string
3) And just why would you not double check that the string returned is actually random. If you spend 2 minutes doing a quick test you'd spot that the letters 'A' and '9' are only returned half as often as all the other chars.

Capt'n Midnight · 19-12-2019 11:06pm

Neglecting to update to SSD Firmware Version HPD8 will result in drive failure and data loss at 32,768 hours of operation

GhostyMcGhost · 20-12-2019 11:01am

Capt'n Midnight wrote: »

Neglecting to update to SSD Firmware Version HPD8 will result in drive failure and data loss at 32,768 hours of operation

Could have been worse. Could have been 256 hours

lawred2 · 20-12-2019 11:10am

Sephiroth_dude wrote: »

Would the following be considered a "Coding Horror"

public void setFirstName(String firstName){
	  
	  if(firstName.length() < 5){
		 
		  throw new IllegalArgumentException("NAME LENGTH IS TOO SHORT! ");
	  }
	  this.firstName = firstName;
  }

it would be the work of an idiot for sure

where did he pull that business rule from?

iLikeWaffles · 20-12-2019 2:03pm

lawred2 wrote: »

it would be the work of an idiot for sure

where did he pull that business rule from?

Must not like people named Paul

Capt'n Midnight · 20-12-2019 5:57pm

iLikeWaffles wrote: »

Must not like people named Paul

Worse still it's not cryptographically secure if Alice can't talk to Bob.

Berserker · 20-12-2019 9:50pm

lawred2 wrote: »

it would be the work of an idiot for sure

where did he pull that business rule from?

Likely that he works in an organisation that has poor business analysis and people make up rules on the fly from time to time. The most senior dev in the place I work is a terror for it. Even makes up business rules based on her experience and logs them as bugs. Some of the rules are daft.

swampgas · 20-12-2019 10:10pm

Capt'n Midnight wrote: »

Worse still it's not cryptographically secure if Alice can't talk to Bob.

On the upside, looks like Eve won't get a look in either.

Capt'n Midnight · 08-01-2020 11:11pm

https://www.theregister.co.uk/2020/01/08/boeing_737_ng_cockpit_screen_blank_bug/

Boeing's 737 Next Generation airliners have been struck by a peculiar software flaw that blanks the airliners' cockpit screens if pilots dare attempt a westwards landing at specific airports.

this comment

270 degrees ?

hmmmm

tan(270) error infinite result?

typesafe · 14-01-2020 2:59pm

Rulmeq wrote: »

I worked with a guy who was tasked to code something similar, his first name was 2 letters (Wu), and I think they had the min set to 3 or 4. He wrote the code, because "it was a requirement" but the stupid really burns sometimes.

Famous 40 Falsehoods Programmers Believe About Names:
1. People have exactly one canonical full name.
2. People have exactly one full name which they go by.
3. People have, at this point in time, exactly one canonical full name.
4. People have, at this point in time, one full name which they go by.
5. People have exactly N names, for any value of N.
6. People’s names fit within a certain defined amount of space.
7. People’s names do not change.
8. People’s names change, but only at a certain enumerated set of events.
9. People’s names are written in ASCII.
10. People’s names are written in any single character set.
11. People’s names are all mapped in Unicode code points.
12. People’s names are case sensitive.
13. People’s names are case insensitive.
14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those.
15. People’s names do not contain numbers.
16. People’s names are not written in ALL CAPS.
17. People’s names are not written in all lower case letters.
18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
19. People’s first names and last names are, by necessity, different.
20. People have last names, family names, or anything else which is shared by folks recognized as their relatives.
21. People’s names are globally unique.
22. People’s names are almost globally unique.
23. Alright alright but surely people’s names are diverse enough such that no million people share the same name.
24. My system will never have to deal with names from China.
25. Or Japan.
26. Or Korea.
27. Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have “weird” naming schemes in common use.
28. That Klingon Empire thing was a joke, right?
29. Confound your cultural relativism! People in my society, at least, agree on one commonly accepted standard for names.
30. There exists an algorithm which transforms names and can be reversed losslessly. (Yes, yes, you can do it if your algorithm returns the input. You get a gold star.)
31. I can safely assume that this dictionary of bad words contains no people’s names in it.
32. People’s names are assigned at birth.
33. OK, maybe not at birth, but at least pretty close to birth.
34. Alright, alright, within a year or so of birth.
35. Five years?
36. You’re kidding me, right?
37. Two different systems containing data about the same person will use the same name for that person.
38. Two different data entry operators, given a person’s name, will by necessity enter bitwise equivalent strings on any single system, if the system is well-designed.
39. People whose names break my system are weird outliers. They should have had solid, acceptable names, like 田中太郎.
40. People have names.

oscarBravo · 14-01-2020 3:56pm

typesafe wrote: »

11. People’s names are all mapped in Unicode code points.

This one intrigues me. What names can't be mapped to Unicode?

typesafe · 14-01-2020 9:15pm

oscarBravo wrote: »

This one intrigues me. What names can't be mapped to Unicode?

Unicode Consortium has Urgently Needed Character proposal procedure for such cases. For example:
IRG N2068 proposal documents a Hanja character approved for use in Korean names.
RG N2078 proposal documents five Kanji characters to be used on Japanese residence cards.

14ned · 22-01-2020 1:57pm

typesafe wrote: »

Unicode Consortium has Urgently Needed Character proposal procedure for such cases. For example:
IRG N2068 proposal documents a Hanja character approved for use in Korean names.
RG N2078 proposal documents five Kanji characters to be used on Japanese residence cards.

Those issues will be fixed eventually, by adding yet more codepoints.

There are far more serious problems with Unicode, in terms of that it can't work correctly no matter what you do for some text representations. Ultimately it was designed by a committee which was starting from a Western viewpoint of 1 codepoint = 1 character, so we got a Western-centric design based around alphabets well known to Western Europeans only. That leads to many possible byte sequences mapping to one text for some scripts, which introduces all sorts of impossible to avoid text corruption for even simple operations like copy and paste.

This problem is worst for Asian and Indian text, see https://en.wikipedia.org/wiki/Unicode#Issues. It is suspected much worse is to come from African text soon.

Niall

bpmurray · 31-01-2020 9:18pm

14ned wrote: »

Those issues will be fixed eventually, by adding yet more codepoints.

There are far more serious problems with Unicode, in terms of that it can't work correctly no matter what you do for some text representations. Ultimately it was designed by a committee which was starting from a Western viewpoint of 1 codepoint = 1 character, so we got a Western-centric design based around alphabets well known to Western Europeans only. That leads to many possible byte sequences mapping to one text for some scripts, which introduces all sorts of impossible to avoid text corruption for even simple operations like copy and paste.

This problem is worst for Asian and Indian text, see https://en.wikipedia.org/wiki/Unicode#Issues. It is suspected much worse is to come from African text soon.

Niall

Actually, it wasn't designed by committee. Mark Davis, Joe Becker and Lee Collins produced the first version. Since then, additional characters have been added, usually at the behest of the individual countries (who presumably are the experts). One such that I think was wrong was the including of some 14000 precomposed Korean characters - encoding the few jamo instead would have provided a lot of flexibility, including the addition of other Korean characters, but the Koreans wanted it that way. Or I should say, the South Koreans - the North Koreans have claimed that it's all wrong! Even minority languages have been proposed by experts, including Mike Eversen who lived in Ireland for some time.

Probably the single biggest misunderstanding is with the Han Unification: Unicode encodes characters not glyphs, i.e. it encodes the semantics of a character and not how it displays nor its meaning.

I see Ken Lunde is now on the committee. He wrote the CJKV book so is possibly the world expert in this area. As for Indian scripts, many Indians have been so used to ISCII that they don't get Unicode. The major scripts are encoded individually, and there are transcription algorithms that can be used to convert between them and even roman script. Ligatures are not encoded in any other script, since that is a function of rendering, not one of encoding, although precomposed accented characters are included as are a few old Arabic ligatures. The red herring of round-trip is something that Unicode never promised so don't expect it.

That Wikipedia article is stretching, creating issues where none exist.

And, for the record, I represented my corporate masters on the Unicode committee for a number of years.

14ned · 02-02-2020 12:20pm

Firstly, that's great extra detail. I knew that Ireland punched above its weight in Unicode standards (for some reason), but I'm very much a few links removed from the Unicode coal face. On WG21, any papers involving text must go before the Unicode study group for review and approval, and from there you get second hand information. But almost never do you hear anything from the horse's mouth, as it were.

bpmurray wrote: »

Actually, it wasn't designed by committee. Mark Davis, Joe Becker and Lee Collins produced the first version. Since then, additional characters have been added, usually at the behest of the individual countries (who presumably are the experts).

"Design by committee" very often involves a small group of people who come up with something behind closed doors, and then steer it into a standard. Myself and about five others did the modern i/o proposal for C++, for example, even though 300 or so folk sit on the committee, and will have a hand in its design.

Much of the "design by committee" problem stems from having to deliberately design a technical thing to be able to pass through a body of experts. So, you often don't choose a technically ideal way, because it's unexplainable to others in a short enough period of time to be realistically achievable.

I don't know enough about computer encoding of human script to say what would be better than Unicode, but I have talked to those who do, and they say that Unicode, for better or worse, is at least a large improvement on what came before, even if it has serious problems in certain parts. I think on that we can all agree.

Niall

Capt'n Midnight · 07-04-2020 10:10pm

https://www.theregister.co.uk/2020/04/02/boeing_787_power_cycle_51_days_stale_data/

The US Federal Aviation Administration has ordered Boeing 787 operators to switch their aircraft off and on every 51 days to prevent what it called "several potentially catastrophic failure scenarios" – including the crashing of onboard network switches.

Another symptom was for the flight management system to simply go blank and freeze, triggered by selection of a standard arrival path (STAR) with exactly 14 waypoints – such as the BIMPA 4U approach to Poland's rather busy Warsaw Airport.

Wombatman · 20-04-2020 9:23am

Anybody speak COBOL?

https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure

oscarBravo · 20-04-2020 10:34am

I used to be fluent in RPG, but I managed to miss out on the COBOL fad.

DublinWriter · 23-04-2020 6:53pm

Wombatman wrote: »

Anybody speak COBOL?

Did it in my first year in TCD back in 89 and even then it seemed antiquated.

PeopleSoft (now Oracle HR) still uses it for batch report processing AFAIK.

antimatterx · 23-04-2020 7:41pm

DublinWriter wrote: »

Did it in my first year in TCD back in 89 and even then it seemed antiquated.

PeopleSoft (now Oracle HR) still uses it for batch report processing AFAIK.

Why can't these companies upgrade to modern tech? I always worry what the hindrance is

oscarBravo · 23-04-2020 7:45pm

antimatterx wrote: »

Why can't these companies upgrade to modern tech? I always worry what the hindrance is

When you have mission-critical software that Just Works, replacing it with software that might not work is a difficult risk to justify.

swampgas · 24-04-2020 1:10am

antimatterx wrote: »

Why can't these companies upgrade to modern tech? I always worry what the hindrance is

It's a good question.

Massive numbers of man-hours have gone into legacy systems, and quite often the original developers are long, long departed. If those systems are mission-critical then anything to replace them has to "just work" - quite a tall order.

I worked for years on a telco platform that had it's own proprietary programming language that ran on custom hardware. It turned out to be easier and more reliable to build a fast emulator for the old hardware using modern CPUs, and keep the old software, than it was to convert the existing code to a new language. (They tried ... and ended up with a different product. But that's another story.)

rdhma · 24-04-2020 2:04am

A long time ago, I took over maintenance of a certain program.
At one point in the program, an array had been filled with values, which could determined by a simple formula.
some hundreds of elements were assigned in the code like this:
element[16]= 128
element[17]= 255
...
...

Yes, every one was typed in by hand like that. If the numbers had needed to be changed, too bad.
I wrote a six line loop to do the job instead.
"Who wrote this? It's unbelievable", I would have said to the boss.
But I didn't say that, as he was the one who wrote it.

Slutmonkey57b · 24-04-2020 9:48am

antimatterx wrote: »

Why can't these companies upgrade to modern tech? I always worry what the hindrance is

In my experience the answer is always "incompetent management". When you think about it, these systems are generally so old that the companies who put them in at the time were probably cutting edge and management were confident and understood the need for infrastructure. Modern managers are generally accountants and outsourcers at heart and they don't care about infrastructure until it breaks, at which point they'd rather spend a few million paying for a consultants report that whitewashes then from blame than spend the same amount to actually fix the root cause.

Earthhorse · 24-04-2020 10:16am

At the risk of ringing in a cliché a big part of the problem is inadequate specifications. The old system does what it's meant to and everybody "knows" what that is but no one can articulate it in clear, understandable English. So you end up trying to port code back to intent and back to code again. Incredibly difficult.

Another issue is resources. State bodies always seem overfunded but a lot of the time that's because they don't get big capital investment in order to improve systems so they never streamline and huge funding is required just to keep them running. It's sort of a Catch-22.

Either way, I think it's always easy from the outside to think you have all the answers. It's always more difficult once you're the one involved.

GreeBo · 24-04-2020 12:21pm

Earthhorse wrote: »

At the risk of ringing in a cliché a big part of the problem is inadequate specifications. The old system does what it's meant to and everybody "knows" what that is but no one can articulate it in clear, understandable English. So you end up trying to port code back to intent and back to code again. Incredibly difficult.

Its always this in my experience.
When someone starts to notice the maintenance costs or outages from the old software the idea to rewrite springs up.
Problem is that the requirements are often literally "The new system should do the same as the old system with transparent migrations"
No one has a clue what the old system does from a business requirements standpoint.

It often makes far more sense to start from scratch and figure out what you want the new system to do (avoids rewriting features that no one uses) but that involves difficult conversations with customers so you end up in emulator hell.
I've seen emulators on top of emulators on top of emulators, its not pretty and it doesnt reduce the TCO at all, makes things more brittle (oh emulator 4 has a 2K limit on message sizes and emulator 2 cant handle double byte characters)

If you are used to startups or small business then these rewrites seem so simple and logical, if you are used to billion dollar companies that have 50 years of legacy your opinion changes.

Slutmonkey57b · 24-04-2020 12:31pm

A lot of that can be avoided if you're prepared to create a greenfield infrastructure and run it in a shadow mode beside the legacy for a reasonable period. Discover gaps as you go and fix. However the assumption seems to be that the only way to do things is to try and scrape everyone's brain, and have a grand switchover day on something you designed 5 years ago in a meeting room.

Earthhorse · 24-04-2020 1:42pm

You can certainly do that. Though I'm not 100% sure how a shadow mode would work for, say, communicating with 3rd party systems. A lot of buy in is required from the client though, especially where there may be a wide variety of configurations (so each one will need to run in shadow mode). Perhaps you've seen this work in the wild and I'd certainly be interested in hearing how it did but it doesn't sound much better than picking people's brains. "Discover gaps as you go and fix" is exactly how most projects I've been on operate; can't say I'm a fan.

oscarBravo · 24-04-2020 2:08pm

GreeBo wrote: »

It often makes far more sense to start from scratch and figure out what you want the new system to do...

Pretty sure I've told the story before, but I was asked to modify a giant report shortly after starting a new job. I gave up on trying to understand the code, and instead reverse-engineered the end-user's requirements, and rewrote it from scratch. When the old and new versions of the report didn't match I was told my report was wrong - I had to painstakingly prove, line by line, that the old report was riddled with rounding errors and that in fact mine was correct.

GreeBo · 24-04-2020 2:13pm

Earthhorse wrote: »

You can certainly do that. Though I'm not 100% sure how a shadow mode would work for, say, communicating with 3rd party systems. A lot of buy in is required from the client though, especially where there may be a wide variety of configurations (so each one will need to run in shadow mode). Perhaps you've seen this work in the wild and I'd certainly be interested in hearing how it did but it doesn't sound much better than picking people's brains. "Discover gaps as you go and fix" is exactly how most projects I've been on operate; can't say I'm a fan.

Yeah, if the system is a pipeline or workflow that calls out to multiple other backends including 3rd party or maybe even billing you cant just shadow it.

You end up with yet more emulators and even then, unless you know every possible input and ouput you are just guessing.

The bottom line is that in a lot of cases its not worth the business risk to try to change this stuff as the ultimate client can often have very penal contract clauses.

Its only when the fragility of the system outweighs this risk that something starts to happen and by then its often a multi year, multi million dollar effort.

GreeBo · 24-04-2020 2:15pm

oscarBravo wrote: »

Pretty sure I've told the story before, but I was asked to modify a giant report shortly after starting a new job. I gave up on trying to understand the code, and instead reverse-engineered the end-user's requirements, and rewrote it from scratch. When the old and new versions of the report didn't match I was told my report was wrong - I had to painstakingly prove, line by line, that the old report was riddled with rounding errors and that in fact mine was correct.

But even this is a great example of the difficulties of "upgrading" things.

You could have had hundreds of clients who's own software *depended* on those errors. Fixing them on your side could cost them millions on their side.

(I often deal with clients who's own software is ancient and in fact they dont even have developers anymore, its all outsourced on demand)
Changing your code now involves significant business risk across two businesses.

oscarBravo · 24-04-2020 2:19pm

GreeBo wrote: »

You could have had hundreds of clients who's own software *depended* on those errors. Fixing them on your side could cost them millions on their side.

Case in point: Excel still thinks 1900 was a leap year, because fixing that bug would break spreadsheets.

Earthhorse · 24-04-2020 2:25pm

GreeBo wrote: »

You could have had hundreds of clients who's own software *depended* on those errors. Fixing them on your side could cost them millions on their side.

100%

I have found things that are clearly wrong (not major things in fairness) in the software I'm porting. But as other reports rely on this wrong information I've been told to leave it as is.

johnmcdnl · 28-04-2020 1:00am

oscarBravo wrote: »

Case in point: Excel still thinks 1900 was a leap year, because fixing that bug would break spreadsheets.

Better yet -- Excel actually deliberately implemented this as IBM Lotus which was the major spreadsheet software at the time had this bug. MS needed their software to be compatible with Lotus to help attract customers and the 'bug' itself is now part of the official specification http://www.ecma-international.org/publications/standards/Ecma-376.htm

Users of Excel now have hacks or whatever in place to fix this issue if it's important to them, so if you actually 'fixed' the bug, you'd actually potentially cause a massive headache for every one of your customers who have already implemented their systems knowing about this issue.

beauf · 28-04-2020 2:40am

Wasnt this the problem that XML and data transformations were meant to solve. Only the solutions are more overhead than the problem it was trying to solve.

I feel very jaded. Got every t shirt for every problem mentioned in this thread. I don't feel people want solutions and especially not innovation. They want to you to tick all the boxes on their change requests. They do not want you to point out any problems that you might have seen a million times before.

I was trying to think of one thats a common denominator for me these days. I think it's setting deadlines and release dates without any analysis or concept of how long something is going to take. Also
information silo's. All projects seem to run using a secret form of Chinese whispers.

DublinWriter · 28-04-2020 12:59pm

T'is all about politics.

Middle management and non-technical PMs/BAs want to tick the big project closure box at the end of the day and move on with their brilliant careers to the next glittering project. They will chose the path of least resistance in terms of change and usually be over cautious and not take on board wider holistic issues.

beauf · 28-04-2020 5:42pm

DublinWriter wrote: »

...Middle management and non-technical PMs/BAs ...

I think the issue is we have middle management masquerading as PMs/BAs but have no idea how to do either.

GreeBo · 28-04-2020 5:46pm

beauf wrote: »

Wasnt this the problem that XML and data transformations were meant to solve. Only the solutions are more overhead than the problem it was trying to solve.

I feel very jaded. Got every t shirt for every problem mentioned in this thread. I don't feel people want solutions and especially not innovation. They want to you to tick all the boxes on their change requests. They do not want you to point out any problems that you might have seen a million times before.

I was trying to think of one thats a common denominator for me these days. I think it's setting deadlines and release dates without any analysis or concept of how long something is going to take. Also
information silo's. All projects seem to run using a secret form of Chinese whispers.

People dont want innovation if innovation isnt required.
What percent of innovations actually result in something that makes money for the company, 1% maybe? Theres a reason the IDA gives support for R&D, even to multinationals, its because mostly it goes nowhere.

If your company isnt in the business of R&D then you trying to solve some business problem via a GraphDB for 12 months and failing miserably isnt going to do much for the future of your company.

beauf · 28-04-2020 6:20pm

GreeBo wrote: »

People dont want innovation if innovation isnt required.
What percent of innovations actually result in something that makes money for the company, 1% ...

If you have metrics on the before and after that's easy calculated. These days I've stopped trying to sell what should be obvious to the clueless. They won't look at the metrics or understand them even if created them. Metrics are handy for promotions and job interviews. That's mainly why I still do them.

Recently I had to cover for someone else, and got fed to with some insane support they were doing, that now I was getting tasked with. I rewrote a bit of code here on a couple of systems, changed a couple database jobs, changed the workflow slightly. End result its no longer generating work items for 4 or more people and generating any of the associate support emails and calls back and forth.

I don't really care what the value of this is for organision. I only care that I'm no longer interrupted by this dumb task.

Most of the projects that innovate that I've been involved in have mostly been successful. It's usually the ones that stifle innovation and lateral thinking, that fail. Oh and also those run by business heads out of their technical depth. Often because they simply don't know how to run a project or take advice.

beauf · 28-04-2020 6:29pm

GreeBo wrote: »

People dont want innovation if innovation isnt required.
What percent of innovations actually result in something that makes money for the company, 1% maybe? Theres a reason the IDA gives support for R&D, even to multinationals, its because mostly it goes nowhere.

If your company isnt in the business of R&D then you trying to solve some business problem via a GraphDB for 12 months and failing miserably isnt going to do much for the future of your company.

One company I was in the bean counters got control and shut down the RD unit which was probably about 100 people in it. Strong mix of software engineering and creatives.

Within a year or two that company was in trouble and within two or three years asset stripped and consumed by a competitor. Without RD they didn't innovate didn't keep their product fresh and lost their competitive edge. They'd also lost all the problem solvers once RD was gone.

If your R&D is not being productive it's not being managed properly.

Coding Horror

Comments