Why Don't We Have Better Practices?

Question

Why Don't We Have Better Practices?

Viewing 15 posts - 16 through 30 (of 45 total)

You must be logged in to reply to this topic. Login to reply

thelenj SSC Eights! Points: 869 More actions · Answer 1

The only reason we don't have better practices is because the tech companies earn a great deal of money by constantly changing things. New languages, new IDEs, new frameworks, new standards, new run times - all the churn sells software, books, seminars, and training sessions.

You don't have time to get good at any one way of doing things because about the time you're comfortable with version 1.0 an new and improved version 2.0 is launched along with all the requisite training materials.

chrisn-585491 SSCoach Points: 16006 More actions · Answer 2

Poor management.

Take the case of Target. Were IT professionals and responsible aware people in charge of securing their network??. Maybe at some level, but not where the buck stopped or where budgets were decided. The ex-CIO was more interested in social media and marketing than securing their network. They had money to predict pregnancy among customers but not enough to ensure security.

Ralph Hightower SSCrazy Points: 2843 More actions · Answer 3

Try programming in APL. That is one bizarre language!

david.wright-948385 SSCarpal Tunnel Points: 4039 More actions · Answer 4

skeleton567 (5/15/2014)
This is exactly why I oppose the development of computer controlled vehicles.

I'm kinda hoping that the software controlling automatic cars will fall under similar standards as airplane (particularly military) control software. If GM can have this much trouble over an ignition switch, imagine how much they'd be able to get wrong if they automate the driving of the car :w00t:

Koen Verbeeck SSC Guru Points: 259085 More actions · Answer 5

david.wright-948385 (5/15/2014)
skeleton567 (5/15/2014)
This is exactly why I oppose the development of computer controlled vehicles.
I'm kinda hoping that the software controlling automatic cars will fall under similar standards as airplane (particularly military) control software. If GM can have this much trouble over an ignition switch, imagine how much they'd be able to get wrong if they automate the driving of the car :w00t:

What if they run java and right before the car needs to break for a traffic jam, the garbage collector kicks in...

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

Chris Wooding SSCarpal Tunnel Points: 4530 More actions · Answer 6

The IT industry is frequently compared to bridge-building - normally in a negative way. To put it into perspective, bridge-building has been going on for centuries, if not millennia; by contrast, IT is comparatively new. I'm pretty sure that a fair number of cavemen died using inadequate bridges during the industry's infancy. The rate of technological change is exponentially different too. Bridge-building has had approximately three technology changes in its history - wood and rope to stone and then to concrete and steel. Compare that with IT. If bridge-building had advanced as quickly as IT, then every time you wanted to cross the English channel, you'd be able to build your own temporary bridge for about tuppence and walk!

Ian Massi SSCertifiable Points: 5931 More actions · Answer 7

I doubt I'm the only one who read that metaphor and though, "Man, wouldn't it be great to have a software development project as clearly defined as a bridge?"

Me: "What's the requirements?"

Project manager: "We need to get cars from one side of the river to the other."

INSERT INTO EastBank (Car) SELECT Car FROM WestBank WHERE isGoingToWestBank = 1

INSERT INTO WestBank (Car) SELECT Car FROM EastBank WHERE isGoingToEastBank = 1

There we go - I'm taking lunch.

david.wright-948385 SSCarpal Tunnel Points: 4039 More actions · Answer 8

Koen Verbeeck (5/15/2014)
What if they run java and right before the car needs to break for a traffic jam, the garbage collector kicks in...

😛

Koen Verbeeck SSC Guru Points: 259085 More actions · Answer 9

Ian Massi (5/15/2014)
I doubt I'm the only one who read that metaphor and though, "Man, wouldn't it be great to have a software development project as clearly defined as a bridge?"
Me: "What's the requirements?"
Project manager: "We need to get cars from one side of the river to the other."
INSERT INTO EastBank (Car) SELECT Car FROM WestBank WHERE isGoingToWestBank = 1
INSERT INTO WestBank (Car) SELECT Car FROM EastBank WHERE isGoingToEastBank = 1
There we go - I'm taking lunch.

Although the requirements are simple, implementations are not. What if the banks of the river are not stable enough for the concrete pillars? And so on...

Engineers make it easier though: g equals 10, Pi equals 3 and at the end we multiply everything by 3 just to make sure.

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

skeleton567 SSCertifiable Points: 5677 More actions · Answer 10

Ralph Hightower (5/15/2014)
Try programming in APL. That is one bizarre language!

I'm not sure without researching it if APL and what we called in the old days Assembler Language are the same thing, but I've "been there, done that". It was a very efficient, fast, compact, precise tool and we always used it for the most exacting critical tasks. You had to be a real 'programmer' to use it, and we didn't have the naive folks 'managing' development. Real, experienced Systems Analysts were in charge and we got things right in development. Bugs in software were taken seriously and all identified were fixed without waiting for a 'next release'. Then along came the likes of COBOL which made so-called 'programmers' of those who weren't and shouldn't have been.

Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )

david.wright-948385 SSCarpal Tunnel Points: 4039 More actions · Answer 11

skeleton567 (5/15/2014)
Then along came the likes of COBOL which made so-called 'programmers' of those who weren't and shouldn't have been.

Horses for courses: if you produce a product using Cobol, you accept Cobol's shortcomings and those of its programmers, but the cost of production are lower. If you write assembler for a REAL realtime OS, you get a whole lot more complexity and higher costs, but better control of, and clearer visibility in the result.

Michael Meierruth SSChampion Points: 10051 More actions · Answer 12

Ian Massi (5/15/2014)
I doubt I'm the only one who read that metaphor and though, "Man, wouldn't it be great to have a software development project as clearly defined as a bridge?"
Me: "What's the requirements?"
Project manager: "We need to get cars from one side of the river to the other."
INSERT INTO EastBank (Car) SELECT Car FROM WestBank WHERE isGoingToWestBank = 1
INSERT INTO WestBank (Car) SELECT Car FROM EastBank WHERE isGoingToEastBank = 1
There we go - I'm taking lunch.

I see no error handling here. While on the bridge, what if I get a flat tire or run out of gas or my wife shouts at me and says we need to turn back IMMEDIATELY because she forgot her lipstick?:w00t:

Can all this be handled in a single transaction?:cool:

skeleton567 SSCertifiable Points: 5677 More actions · Answer 13

david.wright-948385 (5/15/2014)
skeleton567 (5/15/2014)
Then along came the likes of COBOL which made so-called 'programmers' of those who weren't and shouldn't have been.
Horses for courses: if you produce a product using Cobol, you accept Cobol's shortcomings and those of its programmers, but the cost of production are lower. If you write assembler for a REAL realtime OS, you get a whole lot more complexity and higher costs, but better control of, and clearer visibility in the result.

The problem, 'of course, of course' was that everyone was convinced it was better because it was new and shiny. Decision makers rarely understand what's under the hood.

Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )

david.wright-948385 SSCarpal Tunnel Points: 4039 More actions · Answer 14

skeleton567 (5/15/2014)
Decision makers rarely understand what's under the hood.

Ain't that the flippin truth :doze:

PHYData DBA SSCertifiable Points: 7541 More actions · Answer 15

There are very good and useful rules and paradigms for writing excellent and efficient software.

Unfortunately most software is written with using any of them or using them in a counterproductive way.

IMHO - There are so many things out there to help Software developers and Systems Architects do what you talked about today. I would like to apologize to Steve for the next part of my post, but it was an easy example.

These existing tools and methods are like the Spell and Grammar checker that was used to proof you editorial.

If they are not used correctly, if the method is inadequate, or the execution is incomplete then you end up with a product structured like this sentence.

. Why do we have so conflict and strange practices in many software systems? Why haven't we decided upon more good security practices that we widely disseminate?

Instead of on like this

Why do we have conflicting ideas and strange practices in so many software systems?
Why haven't we decided upon better security practices that we widely disseminate?

This thought has come to mind during every code review I have been in since my first programing class in 1982:

It is usually easier and faster to correct and compile a thousand lines of bad code a thousand times than write one line of good code that does the exact same thing.