Comment Re:Yes, blame the developers! (Score 1) 156
I have blamed the developers, but the greatest source of issues I've seen usually circles back to managers and users.
These fundamental issues/problems are still going on
- Prototypes are taken directly into production. The prototypes intention was to actually flesh out the business rules. After initial testing does it do what the customer wants or can it do what the customer wants, customer is happy and wants it right now.
So how did the prototype get so poor -- after 4 or 5 iterations where the developer saw multiple weeks of work get dumped and trashed, the code got more turn and burn. Backend gets sloppy and just good enough so the shiny front end works.
It may not be business rules, insert any other complex issue here that is poorly described and spec'd.
- I have seen where developers get assigned to departments where they are reporting directly to a business manager or someone in sales. They churn out shiny code. Business Manager or Sales manager are all happy because they are getting new tools.
Actually saw a horror story of this. Developer went and asked and got a view created in a database. Application allowed for an unintentional SQL injection. Data was lost and nobody noticed a large chunk of data missing for 2 weeks. The DBA got blamed. They just didn't want to blame an out of control developer.
But basically it pointed back to a developer who was churning out non-peer reviewed code. Which is actually a management problem.
- Then there is the industry publishing problem. (This I think is one of the biggest problems)
I haven't read a beginners or intermediate programming book in awhile, but when I did, I never saw chapters that addressed these issues. Example after example never checking for buffer over flow or SQL injection. If it is such an easy problem to deal with , why aren't they addressed in beginning example code.
- Prototypes are taken directly into production. The prototypes intention was to actually flesh out the business rules. After initial testing does it do what the customer wants or can it do what the customer wants, customer is happy and wants it right now.
So how did the prototype get so poor -- after 4 or 5 iterations where the developer saw multiple weeks of work get dumped and trashed, the code got more turn and burn. Backend gets sloppy and just good enough so the shiny front end works.
It may not be business rules, insert any other complex issue here that is poorly described and spec'd.
- I have seen where developers get assigned to departments where they are reporting directly to a business manager or someone in sales. They churn out shiny code. Business Manager or Sales manager are all happy because they are getting new tools.
Actually saw a horror story of this. Developer went and asked and got a view created in a database. Application allowed for an unintentional SQL injection. Data was lost and nobody noticed a large chunk of data missing for 2 weeks. The DBA got blamed. They just didn't want to blame an out of control developer.
But basically it pointed back to a developer who was churning out non-peer reviewed code. Which is actually a management problem.
- Then there is the industry publishing problem. (This I think is one of the biggest problems)
I haven't read a beginners or intermediate programming book in awhile, but when I did, I never saw chapters that addressed these issues. Example after example never checking for buffer over flow or SQL injection. If it is such an easy problem to deal with , why aren't they addressed in beginning example code.