Are you over engineering in your work?
My boss at my previous project often reminded developers that “Don’t over engineer for me”.
As a SQL developer, sometimes we are stuck in our certain believes so religiously that we forget that we are working in a team, whose performance is not measured by how many “bells and whistles” we can add to our technical work, but by how efficient we are, and how quick we can respond to the business needs.
I can detect the disgusting tone in his voice when a developer told me that he couldn’t find any ODBC connection to a database in a spreadsheet report a user forwarded to him. I asked him what is he looking for in the report. He said, “Somebody must have pasted thousands of those data into this spreadsheet manually, because I couldn’t find any ODBC connection in this spreadsheet”. He is expecting that this report is generated dynamically. I told him that this was an adhoc report I did a few months ago. I didn’t bother to automate this report in SQL Reporting Services at the time. I told him that I wrote some simple SQL query to get the data and export it to the spreadsheet.
He immediately declared, “I am a strong believer (in SQL Reporting Services). Anything can be automated”. I told him two reasons I didn’t bother.
One, I didn’t feel like it. They only need this kind of report a couple times a year, and the data elements they need and the report parameters are all different.
Two, the user had a long list of employee IDs that need to be used. Allowing users to load their data files into our server can be a real challenge, especially in an environment where several un-trusted network domains exist.
He still insisted that he would give it a try to automate it.
That’s when my boss repeated his reminder of “Don’t over engineer for me”, when the developer declared his pursue to automate the report again.