I learnt this from hard experience. Any programmer’s natural instinct is to design the most robust & generic solution they can conceive. But once you’ve done it, you can then think of 20 ways to improve it and make it even more generic.
But in truth, 99.999% of the time a generic solution is not required. Things will generally be very specific to a certain situation, and in the long run the only thing you’re doing is giving yourself or your follower a maintenance nightmare.
If a Excel spreadsheet, or Sharepoint list, or god forbid, an Access database will do the trick, why roll a new SQL Server database, generate a custom data access layer and do 2 weeks worth of development on a first draft?
If you give the user a custom spreadsheet that took you a few hours to generate, it will point out weaknesses in the process/solution very quickly and you can then build out from that later.
If you can deliver a 80% solution to a user’s problem within a day, they will think you’re a god every time. If you take 2 weeks with the initial design every time, they WILL stop asking you for solutions. At some point someone in management will realise that you’ve stopped adding value to the company, and the inevitable will happen.
That being said, I’m all for refining a solution to be a bit more generic if there is a real application, and a real need for that, but design and deliver the specific solution, iron out any problems and then take it further.