The one I get constantly is we want "custom reporting". Well what the hell is that really? Why, why, why do you need that? Then I just build a new feature they will actually use and defer "custom reporting" for another month.
I see this all the time... custom reporting, reports... I have seen this so many times in so many places and I wonder why the fuck are people asking about it. Most of the time they have little clue of what they want reported, or how they want the data to look like. Nearly 100% of the time what they mean by reporting is "join all the tables that have a foreign key, force join all the ones that do not have a foreign key by using a union against some arbitrary value picked at most-likely-to-be-the-right-one and dump everything on an "excel spreadsheet". This is the golden standard most people go by.
I worked with a guy who specialized in custom reporting tools and pipelines. He said that a majority of the time people are asking for custom reporting tools, it’s because the app’s built-in tools for sorting/filtering/aggregating data aren’t answering the questions they are asking.
Now whenever someone brings that up, I ask “What question are they wanting the answer to?”. It usually leads to either a new feature or just clarifying where that question can be answered. Looks like you’ve caught onto that same school of thought.
Sometimes people just want to feed data into their own warehouse so they can query data across different pieces of software, or they are too stubborn to get to the bottom of what question they’re trying to answer.
Sometimes "reporting" / "monitoring" is how someone does an end-run around normal product and engineering, and we skip adding what ought to be a feature or domain concept.
For example, suppose someone wants special logging whenever a certain field is edited... And then you find out their real goal is to be able to copy-paste old values back in when someone calls up support and says "oops something went wrong." Now the reporting tool is an intermittent part of our customer support.
In contrast, imagine if there was a real "settings events" table that recorded changes in the app and users could go see them. Or a new concept of "revisions", instead of single mutable field.
This is absolutely the reality. Previous company my first project was on team "improving reporting", and chasing all kinds of gnarly performance tuning to make queries and sorting faster, etc. Once we did all this after a few months, come to find out the PM requesting all this missed that what users wanted was one number in hundreds of rows, and sorting so it would show on top...
The team did not like that I pointed out we could have added the number to the home page in a few minutes...
My experience is always "we have a standard SQL server datamart. We just need to put a good reporting tool on that. You're a business analyst and product manager, go analyze some products."
"But can't you just make something exactly like we imagine? We're already paying you and buying stuff is paperwork".
Part of the question may be how do you change the users expectations.
If you are building a product the user already knows, that might not be difficult.
We work in the sleep space, where everyone expects a hypnogram and a sleep score.
Even though these things don't actually tell you anything real. They are of little value to most people, but that is the expectation.
I would say that 'what not to build' is the second most important decision.
The most important decision is what limitations and constraints you are prepared to accept. There are always limitations and constraints but they are rarely identified up-front.
The most difficult, hard-to-revert decisions are those related to hard constraints imposed by the systems and/or data you have to rely on. Maybe it's not physically possible to obtain the data you need to solve the problem you need to solve for the price you need for it to be viable. Maybe you need to be able to process large files which may take many hours to complete. Or your input data grows father than you can process on a single CPU core. Or the security requirements of a particular piece of data means that you can't efficiently connect it to some external piece of data as you need.
I see posts pop up with this sentiment often and I'm of two minds:
- llms let us build exactly what we want fairly quickly nowadays, or at least a prototype and
- being able to build these features (or separate products) quickly is exactly the trap
It’s the same test I keep applying when picking the right problems to solve — does it make the boat go faster?
Who knows this though? It's rarely engineers. Product often has a good sense within their lane. Leadership usually (at good companies) is mostly aligned, with some nuance depending on who's speaking.
It's a good sentiment but rarely a single person's decision.
As I said, I see these pop up and I'm usually annoyed because what new take could someone bring at this point, but I read them every single time :p
I find myself often trapped (enticed?) by how fast and inexpensive it is to build software nowadays and also to learn new things.
Today, was thinking about 1) what do I actually want to build AND maintain? and 2) what do I want to build and maintain that if I didn't do it, someone else probably wouldn't and I'd be really annoyed that it didn't exist in the world?
I dunno, just two current questions I thought you might find interesting, not sure if it adds anything new to the discourse, may be a challenge throughout different parts of human history :-D
In theory sure, in practice programmers are often making a large number of such decisions because nobody else in the org is as invested in the specifics.
I would go one step further. Instead of 5 low impact features, build the one high impact one. Instead of a cheap notifications hub, fix the need for why you need one.
I feel this in my bones. I've literally had to fix outages in products where the failure was a "document store" or a "notification system" haphazardly slapped on by a student under direct supervision of a PM with no experienced technical leadership.
One time it was user profile avatars that took a site down. I work in line of business software, nobody needs avatars.
- one thing i also started doing is indirectly ask about the idea on expert subreddits on reddit and see what people have to say
- one of my latest ideas was to handle spam calls on my android phone
- the way i wanted to do this is to have an app pick up the phone call automatically everytime and ask a bunch of user defined questions
- for example, caller: hi i am angel from XYZ spam company
- audio streams through the app with an LLM processing every word and it asks back "who are you trying to reach?"
- caller doesnt answer in 30 seconds or wrong answer. call dropped automatically and the phone is not even ringing yet
- caller says ABC and the autoresponder immediately asks the next question
- "what is the password to reach abc"
- caller doesnt answer or gives incorrect answer within 30 seconds and call is dropped immediately
- caller gives correct answer and now the phone starts ringing
- obviously the questions are set by the user and it ll change from user to user
- imagine by biggest disappointment when I found out from the r/androiddev group that the permission to actually audio process a phone call is simply not available unless you root your android phone. Its a no-go even on the iphone
- Even if you do root the phone, I haven't gotten a conclusive answer from anyone either on reddit or even here on HN so far on the feasibility of implementing such a feature
I agree with the sentiment here but if you are building anything that relates to finance for the love of god please have a page that's just a list of PDFs of every document that is considered formal communication from the institution. It should have the name of the document, the date it was "sent", and a download link. It should be append only, persistent, and be sorted from most recent to oldest. Like for every party involved we ought to have that.
I have visited quite a bit of small towns that were actively built I suppose in the 60-s, and often see abandoned ambitious or even grandiose projects like a park here, or a community center there - fully built but totally deserted now, often in ruins.
Every time I see those I also see the lesson - count your maintenance costs. It is a nice artificial water channel, yes, but will the city have the money to run it, clean it, supply water, etc.?
Of course I know that the original (real estate) developers did the cost analysis, but when you see those abandoned places - very much objectively you can conclude that they made an error. A miscalculation, or an error in judgement.
--
Back to software I think scope creep causes many problems: the team loses focus, can be demotivated by delivering the features no one needs, etc. - all real and serious problems. But ultimately it is the ever growing maintenance cost that has a real ability to annihilate all team capacity.
Everything we build, however high-quality it is, needs to be maintained and all projects should include this into their "run" phase budget. And growing maintenance costs only aggravate other scope creep issues.
--
And that's the tragedy of being the engineer/engineering manager/CTO even. Exactly like the post says, you don't get "promoted" for stuff you reject to do. I had countless occasions of successfully convincing product teams and boards to abandon or shrink the project, and although I am convinced it did good for the companies in the end - the engineering department ends up being a buzzkill :shrug: . I cope with it, but it never really settled with me. If anyone has the answer to how to approach this healthy I am very much interested in your experience.
I sometimes have a hard time figuring out what shouldn't be built.
The next best thing is to rapidly build the crappiest thing that kind of works. Being a little bit bad on purpose usually helps. Getting trapped in clean code and test coverage ideological hell is precisely what we want to avoid.
I've found that the more aggressive you make your time constraint, the less likely you will wind up committing to some kind of engineering decision that ruins the whole pie.
If the 90 minute rapid prototype doesn't make sense, you didn't waste that much time. It's a lot easier to prove things to stakeholders this way too.
I've turned multi-month product roadmap expansion packs into single day tasks by building the right things at the right times in order to discover what not to build.
Yes. Don't succumb to featuritis. Destroy the barnacles.
The one I get constantly is we want "custom reporting". Well what the hell is that really? Why, why, why do you need that? Then I just build a new feature they will actually use and defer "custom reporting" for another month.
I see this all the time... custom reporting, reports... I have seen this so many times in so many places and I wonder why the fuck are people asking about it. Most of the time they have little clue of what they want reported, or how they want the data to look like. Nearly 100% of the time what they mean by reporting is "join all the tables that have a foreign key, force join all the ones that do not have a foreign key by using a union against some arbitrary value picked at most-likely-to-be-the-right-one and dump everything on an "excel spreadsheet". This is the golden standard most people go by.
Well how else am I supposed to run vlookups to find the right data?
I worked with a guy who specialized in custom reporting tools and pipelines. He said that a majority of the time people are asking for custom reporting tools, it’s because the app’s built-in tools for sorting/filtering/aggregating data aren’t answering the questions they are asking.
Now whenever someone brings that up, I ask “What question are they wanting the answer to?”. It usually leads to either a new feature or just clarifying where that question can be answered. Looks like you’ve caught onto that same school of thought.
Sometimes people just want to feed data into their own warehouse so they can query data across different pieces of software, or they are too stubborn to get to the bottom of what question they’re trying to answer.
Sometimes "reporting" / "monitoring" is how someone does an end-run around normal product and engineering, and we skip adding what ought to be a feature or domain concept.
For example, suppose someone wants special logging whenever a certain field is edited... And then you find out their real goal is to be able to copy-paste old values back in when someone calls up support and says "oops something went wrong." Now the reporting tool is an intermittent part of our customer support.
In contrast, imagine if there was a real "settings events" table that recorded changes in the app and users could go see them. Or a new concept of "revisions", instead of single mutable field.
This is absolutely the reality. Previous company my first project was on team "improving reporting", and chasing all kinds of gnarly performance tuning to make queries and sorting faster, etc. Once we did all this after a few months, come to find out the PM requesting all this missed that what users wanted was one number in hundreds of rows, and sorting so it would show on top...
The team did not like that I pointed out we could have added the number to the home page in a few minutes...
My experience is always "we have a standard SQL server datamart. We just need to put a good reporting tool on that. You're a business analyst and product manager, go analyze some products."
"But can't you just make something exactly like we imagine? We're already paying you and buying stuff is paperwork".
Give them an API with the data so they can get create their own reports. Maybe even charge them per hour to create the custom reports.
I thought "custom reporting" was code for "our in-house dev team is slow".
Personally I think that means they want access to the raw data so they can load it in excel or whatever and run their own reports.
It’s hard decision, but it has to be made.
I’m not building space elevator.
I agree, we must focus all our energies on building the torment nexus!
Or as I like to say “the best way to launch is to cut features”.
As an engineering leader you’ve got to advocate for it against product/design all the time.
The better way is to never have those features in your pipeline already.
Part of the question may be how do you change the users expectations.
If you are building a product the user already knows, that might not be difficult.
We work in the sleep space, where everyone expects a hypnogram and a sleep score. Even though these things don't actually tell you anything real. They are of little value to most people, but that is the expectation.
I would say that 'what not to build' is the second most important decision.
The most important decision is what limitations and constraints you are prepared to accept. There are always limitations and constraints but they are rarely identified up-front.
The most difficult, hard-to-revert decisions are those related to hard constraints imposed by the systems and/or data you have to rely on. Maybe it's not physically possible to obtain the data you need to solve the problem you need to solve for the price you need for it to be viable. Maybe you need to be able to process large files which may take many hours to complete. Or your input data grows father than you can process on a single CPU core. Or the security requirements of a particular piece of data means that you can't efficiently connect it to some external piece of data as you need.
I see posts pop up with this sentiment often and I'm of two minds:
- llms let us build exactly what we want fairly quickly nowadays, or at least a prototype and
- being able to build these features (or separate products) quickly is exactly the trap
Who knows this though? It's rarely engineers. Product often has a good sense within their lane. Leadership usually (at good companies) is mostly aligned, with some nuance depending on who's speaking.
It's a good sentiment but rarely a single person's decision.
As I said, I see these pop up and I'm usually annoyed because what new take could someone bring at this point, but I read them every single time :p
I find myself often trapped (enticed?) by how fast and inexpensive it is to build software nowadays and also to learn new things.
Today, was thinking about 1) what do I actually want to build AND maintain? and 2) what do I want to build and maintain that if I didn't do it, someone else probably wouldn't and I'd be really annoyed that it didn't exist in the world?
I dunno, just two current questions I thought you might find interesting, not sure if it adds anything new to the discourse, may be a challenge throughout different parts of human history :-D
In theory sure, in practice programmers are often making a large number of such decisions because nobody else in the org is as invested in the specifics.
I would go one step further. Instead of 5 low impact features, build the one high impact one. Instead of a cheap notifications hub, fix the need for why you need one.
Saved countless sprints by killing features that sounded cool but didn't solve core problems. Less code, less maintenance.
Building the right thing > building/not building anything
Been there. Wasted months building features nobody wanted, all because we didn't prune the roadmap aggressively enough.
I feel this in my bones. I've literally had to fix outages in products where the failure was a "document store" or a "notification system" haphazardly slapped on by a student under direct supervision of a PM with no experienced technical leadership.
One time it was user profile avatars that took a site down. I work in line of business software, nobody needs avatars.
- one thing i also started doing is indirectly ask about the idea on expert subreddits on reddit and see what people have to say
- one of my latest ideas was to handle spam calls on my android phone
- the way i wanted to do this is to have an app pick up the phone call automatically everytime and ask a bunch of user defined questions
- for example, caller: hi i am angel from XYZ spam company
- audio streams through the app with an LLM processing every word and it asks back "who are you trying to reach?"
- caller doesnt answer in 30 seconds or wrong answer. call dropped automatically and the phone is not even ringing yet
- caller says ABC and the autoresponder immediately asks the next question
- "what is the password to reach abc"
- caller doesnt answer or gives incorrect answer within 30 seconds and call is dropped immediately
- caller gives correct answer and now the phone starts ringing
- obviously the questions are set by the user and it ll change from user to user
- imagine by biggest disappointment when I found out from the r/androiddev group that the permission to actually audio process a phone call is simply not available unless you root your android phone. Its a no-go even on the iphone
- Even if you do root the phone, I haven't gotten a conclusive answer from anyone either on reddit or even here on HN so far on the feasibility of implementing such a feature
- Thank god I did not burn 100 hrs into this
For me, the hard part is knowing when to stop. There’s always one more thing to improve before it feels ready.
I agree with the sentiment here but if you are building anything that relates to finance for the love of god please have a page that's just a list of PDFs of every document that is considered formal communication from the institution. It should have the name of the document, the date it was "sent", and a download link. It should be append only, persistent, and be sorted from most recent to oldest. Like for every party involved we ought to have that.
A chapter in my book features a company that attacks this problem with a “add a button; remove a button” mantra.
Before they add any new UI element, they first look for something they can remove.
Self-promotional link: https://killthehippo.com/
I have visited quite a bit of small towns that were actively built I suppose in the 60-s, and often see abandoned ambitious or even grandiose projects like a park here, or a community center there - fully built but totally deserted now, often in ruins.
Every time I see those I also see the lesson - count your maintenance costs. It is a nice artificial water channel, yes, but will the city have the money to run it, clean it, supply water, etc.?
Of course I know that the original (real estate) developers did the cost analysis, but when you see those abandoned places - very much objectively you can conclude that they made an error. A miscalculation, or an error in judgement.
--
Back to software I think scope creep causes many problems: the team loses focus, can be demotivated by delivering the features no one needs, etc. - all real and serious problems. But ultimately it is the ever growing maintenance cost that has a real ability to annihilate all team capacity.
Everything we build, however high-quality it is, needs to be maintained and all projects should include this into their "run" phase budget. And growing maintenance costs only aggravate other scope creep issues.
--
And that's the tragedy of being the engineer/engineering manager/CTO even. Exactly like the post says, you don't get "promoted" for stuff you reject to do. I had countless occasions of successfully convincing product teams and boards to abandon or shrink the project, and although I am convinced it did good for the companies in the end - the engineering department ends up being a buzzkill :shrug: . I cope with it, but it never really settled with me. If anyone has the answer to how to approach this healthy I am very much interested in your experience.
I sometimes have a hard time figuring out what shouldn't be built.
The next best thing is to rapidly build the crappiest thing that kind of works. Being a little bit bad on purpose usually helps. Getting trapped in clean code and test coverage ideological hell is precisely what we want to avoid.
I've found that the more aggressive you make your time constraint, the less likely you will wind up committing to some kind of engineering decision that ruins the whole pie.
If the 90 minute rapid prototype doesn't make sense, you didn't waste that much time. It's a lot easier to prove things to stakeholders this way too.
I've turned multi-month product roadmap expansion packs into single day tasks by building the right things at the right times in order to discover what not to build.