Considering the title, I should say, “Who actually takes the responsibility for a decision”. I heard so many times sentences like “the customer wanted” for a code that is nothing more than a piece of shit. A developer has to take her or his part of responsibility. When you come to the doctors, do you tell what hurts you, or do you make a prescription for yourself? Who takes the responsibility? Why developers are then so often prepared to blame a customer? I know many times customers can be very stubborn in ordering a foolishness; as a developer, you have to explain to the customer where the ordered “solution” leads to. If you realize this, of course; otherwise, we have to feel pity for your customer.
My words are quite strong so far. Let me support them with an example. I have seen queries that retrieve millions of rows excessively many times, and always it was the same excuse: my customer wanted that. Does your customer really need 3,000,000 rows in a report? Let us do a simple mathematics. In a book, you are quite fast reader if you manage to read 60 pages per hour. Most books have less than 50 rows per page. This means you can read, if you are a fast reader, about 3,000 rows per hour. For 3,000,000 rows, you would need 1,000 hours. This is six months of work. Six months for reading results of a single query? Explain this to your customer, and usually you will get an answer like “Of course I am not going to read this for six months; I will find the rows of my interest in five minutes”. Ask how, and you have your Where condition.
Besides projects, I spend about half of the time on training and mentoring. I am the founder of the Slovenian SQL Server and .NET Users Group. and the main author or coauthor of eleven books about databases and SQL Server. I also developed many courses and seminars for SolidQ.
Latest posts by Dejan Sarka (see all)
- Python for SQL Server Specialists Part 4: Python and SQL Server - April 24, 2018
- Python for SQL Server Specialists Part 3: Graphs and Machine Learning - April 11, 2018
- Python for SQL Server Specialists Part 2: Working with Data - March 22, 2018