March 25, 2015 at 3:37 am
Agree. Taking code from somewhere else can be a good starting point for a new type of task, but you need to take the time to understand what it does
April 1, 2015 at 9:02 am
Steve, when I first read your post, in which you said "we suffer from the chef problem in techology", I thought you were going to make an anology to the saying about too many cooks spoiling the broth. I always like a good kitchen reference, so I was disheartened when I realized you probably didn't mean chef.
😉
April 1, 2015 at 9:17 am
Eric JOATMON (4/1/2015)
Steve, when I first read your post, in which you said "we suffer from the chef problem in techology", I thought you were going to make an anology to the saying about too many cooks spoiling the broth. I always like a good kitchen reference, so I was disheartened when I realized you probably didn't mean chef.😉
The way I understood it, the analogy is that we have more kitchens than we do experienced chefs. In other words, our IT development teams are staffed by the equivalent of short order cooks, which is OK, but there needs to master level oversight and practices to produce quality results.
Think about the role played by chef Gordon Ramsay in that TV show 'Kitchen Nightmares'.
https://www.youtube.com/watch?v=jpgP2KAWyhU&feature=player_detailpage#t=16
We suffer from the chef problem in techology. As more companies look to become software companies, they need to hire more software people. To meet the staffing demand, more and more marginally skilled people will be chosen, and software quality goes down.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 22, 2018 at 8:20 am
Worst recent example was a contract web developer who thought he could get away with 'upgrading' a relational database to non-relational. Project delayed for months while other developers fixed the damage.
Also scalability of code, eg. still see too many cursors which may perform ok on a small initial dataset but cause problems once the database grows.
From a report development perspective, I'm seeing an increase in the use of 'enumerators' embedded and re-used in the application code, instead of using a database table to store a simple ID and description, which can then be accessed for other purposes.
As a SSIS developer, I see reports and queries which have been developed with no thought given to database growth. These eventually require some form of datawarehouse development to offload the performance impact on production databases.
MattF
June 22, 2018 at 8:38 am
After reading the editorial, I had in mind a series of specific points I wanted to post here, but now I realize I already made them 3 years ago.
Taking a step back, one general bad T-SQL practice, perhaps the mother of all bad practices, is when a developer tries to solve a new problem by starting with an existing block of code that they really don't understand. For example, there may be a request for a new procedure that returns X and Y, so they copy / paste / retrofit an existing and more complicated procedure that returns A, B, C, X, Y and Z. We all do that; there is no reason to re-invent the wheel. However, some folks simply comment out the columns they don't need but leave behind all the original joins and other logic not required for the problem at hand. Of course, they also throw in a DISTINCT to remove all the pesky duplicate rows caused by the redundant joins, and maybe even add a totally unnecessary ORDER BY clause just for kicks.
Most of the approaches I take to optimization involve taking away and minimizing, not adding and complicating things further.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 22, 2018 at 4:57 pm
The biggest evil I found was unnecessary use of cursors that other mentioned before.
When I just started at my last job, they had an upload process running for 10 hours! Why?
There were a few stored procedures that contained not one, but multiple (unnecessary) cursors each.
All I did was substituting cursors with appropriate Insert/Update/Merge statements.
Upload time went down to 1.5 hour.
------------------------------------------------------------------------------------------------------------------------------------
Buy experiences, not things
June 25, 2018 at 3:00 pm
It is not just the developers. Unlike IT industry, in engineering fields, knowledge is cumulative - one learns what older generations have learned, plus some new stuff. As time goes by, one becomes better in their work, due to experience. With software it is not so. With passage of time, one becomes obsolete, with whatever skills and knowledge they possessed. New "technologies, frameworks and paradigms" and buzzwords are popping up every day, each of then negating the previous one, or at least not needing anything from before. Every new version of Windows requires unlearning what we knew before. Word processors and spreadsheets nowadays are a cruel joke, compared to 30 (!!!) years ago. WordPerfect anybody? Lotus 123, or Harvard Graphics and Lotus Freelance Graphics. Connect text document with spreadsheet data, dynamically, alter the text based on some data in the spreadsheet or a database, in run time. Even if it is possible with today's software, there are not too many people who know how to do it. few years ago, I caught a project manager using desktop adding machine for calculations, then typing the numbers into Excel spreadsheet, you know, sum of rows and sum of columns. To multiply values from two columns- Good forbid, that is for experts. Pivot tables and What-If analysis without wizards - no need for that, buy cubes and like.
Do not program anything, use Microsoft template databases. Somebody should go to jail for those things (MS templates). Actually, in engineering one is responsible for quality of their work. If a building collapses, it is easy to find the party at fault. Either the design was poor, or construction procedures, and we can find the one who did it. Maybe we need something like that for IT industry.
DB admins prefer speed to accuracy. No normalization. Constraints are bad, they slow down the inserts and updates. Do not use natural keys, just add incremental number and that is it - all normalized, fast queries on garbage data. Then we are told that non-relational is the way to go, Mongo-Bongo and such. The data is not up-to-date, perhaps is incomplete, and it takes loong time to retrieve it. Some progress, eh... If one is a .NET developer, they do not need flowcharts to describe program flow - it is so non-object and uncool. In particular, who needs databases. Even "computer science" graduates do not know relational theory. That is equivalent to engineers not knowing mathematics, or a part of it, say geometry.
Perhaps that is why Canadian federal government cannot pay people - the brand new payroll system does not work. One would think that after about 70 years of building and maintaining payroll applications, cumulative knowledge and experience would be there for such a mundane thing. Nope. No proper database, just Java beans and bubbles, or .NET or whatever is the flavour of the day.
Quo vadis Domine?
Viewing 7 posts - 46 through 51 (of 51 total)
You must be logged in to reply to this topic. Login to reply