Home Blog Consumption Resumé


Some Thoughts on Technical Business Realities

  I've been working at DuPont for 2 years now, delivering data products that attempt to provide some insight/value for the logistics branches of the company. I've also spent a bunch of time browsing/reading technical information like various data engineering books, r/dataengineering and r/softwareengineering on Reddit, and just overall have been sort of thinking about the things people say and do when it comes to building software.

  I've found that there seems to be a real disconnect between the "idea" of what software should be and the technical requirements therein and the business requirements that drive development.

  I have come to believe that the end product design for business requirements should be the most minimal and pragmatic design that solve those requirements. And honestly, much of the time, this might be a non-technical solution. If the business currently has no good process for any type of data communication or capture, building a robust system could very well be a waste of time. Perhaps the first step is simply testing a simple excel document sharing process, analyzing the viability of that process, and then developing applications to extend and simplify this process if deemed worthy. In my experience, often we are building complex products that may be hardly touched by users.

  In my opinion there are two main faulty lines of thinking these days when it comes to building internal technical products for business:
  The first camp are business leaders who have little understanding of their own data capabilities and processes and "hope" that tech can solve their problems. It can't!

  The second camp are engineers, usually earlier in their careers or younger, who think that technical skills are worthy in their own right. They're wrong! Technical skills are tools to solve problems. The goal of engineers should be to solve problems. We don't always need complex cloud microservices to do so.

  I haven't dived into specific details but my main point is this: pragmatism should win out above all when it comes to thinking through business problems. Does the product really need to be technical? Will the technical product actually solve the problem? Will people actually use the product? I find there is too much magical and unreal thinking in development for my tastes from all sides.