I will frame the question in terms of a specific C# objective that I am working on right now but I imagine the question is a pretty general one related to the Dunning-Kruger effect, in a way - how do you know how to build an application when you don’t know all the issues you are supposed to prevent?

There is a message hub and I am developing a consumer for it. The original plan was to just create a few background services that get initialized alongside the application, that have a loop to load new messages/events and then process them.

Some time has passed and it feels like I am knees deep in Wolverine, Quartz, Hangfire, MassTransit, transactional outbox and all manner of different related things now. The potential issues are dealing with downtime, preventing loss of messages by storing them in a separate table before processing them, and everyone on the planet has a different idea on how to prevent and solve them and none of them sound simple and straightforward.

Honestly at this point I don’t know enough about which problems are going to appear down the line and if I need to use third party libraries, but I am guessing they exist for a reason and people aren’t supposed to just manually create their own amateurish implementations of them instead? But how do you know where to draw a line when you don’t know exactly the problems that you are supposed to be solving?
What are the problems with having a table for the message queue over a whole 3rd party library for it, or what’s wrong with the MS BackgroundService class? How are you supposed to know this?

  • drolex@sopuli.xyz
    1·
    10 days ago

    I used to manage project deliveries for critical software. Around 10 years in this role. My job was mostly to tell the project manager who wanted to please the customer that if he wanted all the bells and whistles he had to ask for it formally because the team was not being paid otherwise.

    If you don’t have the specs, you have to push and ask for them. Get the involved people in as many meetings as you need until everyone agrees. At least in my field. You can’t guess what the customer wants. The specs are a contract and protect you from future moronic questions from the customer. It is extremely useful to take the time to do them right, otherwise the customer will always find a way to fuck you over.

    So I don’t agree at all that in a senior position you have to magically know what to do. It’s a recipe for disaster. The more senior developers do the strict minimum.

    • CynoOP
      2·
      10 days ago

      Were your project managers always so technically capable? In my experience they represent the business and while they have to ultimately sign off for the development to start, they don’t come up with architecture and design of the solution itself - that should come from the developers/engineering team. At the very least the devs propose possible options and their costs/tradeoffs and then the management picks one, but it’s not like they will come down and tell you whether you should use SQL, Postgres, Mongo or w/e database.

      • drolex@sopuli.xyz
        2·
        10 days ago

        No they weren’t technicals. I was the tech lead.

        It looks very open in your case. Is there no standard or precedent for what you are doing? Something you could lean on?

        Otherwise one of the old wise gits I knew used to say “we don’t sell hammers, we sell holes in the wall”, meaning you don’t care about the tools as long as you reach the desired result.

        Though in our case it was always only C/C++ so…

        Anyway, what I would have done in a case like yours (and it doesn’t necessarily apply) :

        • get customer and PM and some senior dev to understand the needs
        • get dev team to draft a proposal of specs
        • submit specs to PM who submits to customer
        • submit specs to QA for any feedback
        • repeat until we have a stable version of the specs or at least a defined package
        • iterate for the next delivery while dev is working

        The methods, tools and design would be a discussion between me and the dev team

        • CynoOP
          1·
          9 days ago

          This is good advice, thanks. I will definitely get it written down and approved eventually, but the issue is with

          It looks very open in your case. Is there no standard or precedent for what you are doing? Something you could lean on?

          We’re treading new water and doing stuff that nobody in the company is experienced with. We’re getting some ideas thrown at us but that’s the reason for this topic, I don’t feel knowledgeable yet to decide if they are in the right or if they are selling us hammers they like while we actually need something else.

          On the other hand, if I just do the simplest dumbest thing for an MVP, I am again just being a hammer and seeing everything as a nail when I should be learning, adapting and applying the correct tool? I kinda want to use the opportunity and do it better or learn something new.