As a developer who had to deal with a lot of bs from managers, I am going to take the time to go through all your checks and tell you how they are wrong. You are welcome.
0) What problem I am actually trying to solve? Really? That is the first one? Well clearly you haven’t been in the meetings where we were assigned YOUR project. We are trying to solve YOUR problems.
1) A concrete example is called a “User story” you are welcome. We have, at least, dozens of these. You know why we have them? Because it is YOUR job to write them. Ok, ok, I may have been a bit harsh here. It may not be your job, you know, talking to the client and getting specifications of what problems they want solved, that must be the developers job, so go pester them.
2) Who will specifically represent the user of the system? Yeah! That is a question I ask A LOT. You know to whom? MANAGERS. Seriously, who is in charge of managing your developers team? How are the developers aware of production acceptance criteria and you are not?
3) What are the platform constraints? I’m glad you asked, you should have that on the requirements spec, that YOU wrote. If it is some kind of desktop app / mobile app it should be obvious which operating systems it works on, not so obvious which versions (sometimes). Some developers will simply not know for example: “does this work on the latest version of RedHat and on Fedora 22?” should be answered with “I don’t know but it should”, we can test it, but if someone out of the box, has enough knowledge of the specific differences in the kernel of each other, to give you a documented answer I will be amazed. Amazed that such a wonderful team has such a bad manager. If it is a browser app, you also need hardware and OS questions. It doesn’t run on Google or magic, it still runs on hardware, the server needs to be of some SO, the server needs some good memory and internet connection. And you probably want replication and a ton of stuff that its outside the development area and more on the operations team. On the browsers, it is funny you ask, because if you followed W3C it should run on “most” browsers (except the infamous IE). And if you ask me to give you a list of browsers, I will even develop my own browser, put it up on google play and add it to the list. And I will call it “Stupid Managers Question Explorer”.
You don’t ask these questions, you don’t even formulate it as questions. These are requirements. How are your developers even coding without these? I tell you why, because of bad management.
4) What are the memory constraints? These is, on some weird scenarios, a valid question (a first! good boy!). Most of the time the memory constraints come from the client. Phones cannot get memory upgrades, videogame consoles have the memory they have. The server where your web app is running (or the farm, data center, whatever) is not upgrading memory because a dev wants to. On desktop apps, there is this thing called memory pagination (see Wikipedia for: paging), invented in the 1960s, you may want to catch up a bit. Again these are not questions, these are requirements.
5) What are the performance constraints? WHAT!? WHAT!? You KNOW this. This is usability 101. And it also depends on what are you developing. A desktop app can go a little bit slower than a web page. An intranet page can go a little bit slower than an internet page. There are numbers for each of them (I don’t know them over the top of my head, but I hope you can google them). Even on the backend, there is a time limit requirement, you cannot do a calculation of 24 hours cash in more than 24 hours.
Again, AGAIN, these are REQUIREMENTS. You tell your developers, THESE ARE THE LIMITS. Then, the better developers you have, the better they will do it. They do not choose the constraints. And if they go over the top of the constraint, then you either have very bad developers, or you are not understanding the problem. Fun fact: I once was told (and upon rejection, forced to) to reload a database process every 2 minutes (the process took 2 hours, do the math, and yes we hit hardware constraints, pretty fast, sysadmins where not amused).
6) Red flags:
“Generic version”, means common functionality for a ton of things that will consume 1x of time know and save 100x of time in the future. I know you managers are bad at math, so I will tell you in a language you can understand: this is a good thing, be happy. Good boy. Here’s a biscuit.
“I’m creating a framework…” means common functionality (on a different level) that usually consumes around 100x of time and saves 1000000x of time in the future. These may not be a good thing if you are in a hurry or you don’t like long term gains. But it usually, not only saves time for your developers, it eases the learning curve of new developers joining the team.
“Future proofing”. I bow to your superior knowledge of computer science. Oh wait. No. Future proof is a very good coding practice, sometimes very difficult, but critical in some cases. I am going to google you here, you may have wanted to say “Code that is needed in the future” (they are different things, but don’t over think it… like you can), which is a bad practice. Future proofing is essential to scalability, something you may want on your application.
“I really need to refractor this thing”. The red flag should be the contrary. If someone tells you they don’t need to refractor something, questions should be asked. I love how you say that technical debt is a real stuff but future proofing, platform independent and frameworks are lies that developers tell you so they can get away with slacking… or maybe with building a better product, but both seem as bad on the eyes of the ignorant.
7) How much is worth solving? You should have the answer to all of these before you start development. If you stop development and nothing is gained, then you have lost more money (“worth”) than not starting in the first place. Even developers know this, and they are non-manager developers.
8) What specific things will we be able to do that we can’t do now? Again, this should be in the design, spec, document, whatever you have that people write before they code. Usually they write it so people can read it, also, they write those because people like YOU ask them to do so, based on a document that YOU wrote.
What specific things will be cheaper than they are now? “Cheaper” how? They will require less time to compute? They will cost less energy (as in less electricity passing through the computers), oh wait… you are talking about money, because developers know about how economics are managed in their company.
What specific things will be higher quality for the end user than they are now? Wait… you tell your devs to code things for a lower quality in some areas? Are you for real? And you go on the internet and give advice?
9) What previous art solves a similar problem? “Art” hahahaha! I am going to use that one on my next planning meeting. What you are trying to address here is reusability. Something developers are well aware off. We usually say “don’t reinvent the wheel”. Most of the time you managers don’t like it because of an evil complot of developers that we call “open source”.
10) What evidence can you show that this will solve the problem? Ohh a Demo! And pray, how much time are you going to give your devs to build a demo. Is that still cost-effective? Do you think demos are conjured out of thin air? (I will not put it pass you, after all you are a non-technical manager…)
11) What connects to this? If I have to enumerate systems, libraries, protocols… you do realize is going to get pretty technical for your non-technical brain, right? And besides, you whole argument here is that you need to understand this stuff so your developers don’t lie to you… how do you know they are not lying with this? If I tell you that our spring-boot microservice has a dependency on the SFTP protocol due to how it interacts with port 63000 because of the gamma synchronization on raid-1, what are you going to do? write it down in your notepad with a quill and repeat it on your managers meeting?
12) Can you demonstrate a failure? These are called negative testing. Your developers should have a bunch of them, or your test team (do you have testers? because this should be handled by the testers, but sometimes you managers think developers can do testers job and only hire developers to do both things).
And that’s the end to the developers questions, the rest is more managers mumbo jumbo.
If you have reached the end, and think I sounded cocky, overconfident, condescending and even insulting, good! you have read a mile in my shoes. A little bit of truth now, to be a software developer, you need to have passion for coding. It is not a job that can be done by people how don’t like it. That means, that most developers are not doing technobabble (that is the term you were looking for), we simply are used to the technical jargon.
At the end, this whole text seems like a collection of bad things. Most of these questions should not be questions, they should be specs, requirements, user cases… things that you do before the developers start coding. Maybe not a manager, but certainly not the developers, and… I cannot stress this enough, not after they started coding. There are mayor flaws in this kind of working process.