If I have a set of requirements that don’t mention any type of restriction, then I won’t arbitrarily add one - as far as I know, I could be breaking intended functionality. If I’m invested in this, I’ll add it to the list of stuff that needs clarification, otherwise it’s gonna ship as specified, and eventually someone’s gonna file a change request.
Sincere question, are you not expected to clarify questionable business rules? I’ve never worked somewhere that leaving such an obvious issue like “unrestricted fields in a public-facing application” without getting it explicitly stated that that’s intended functionality wouldn’t have gotten me fired instantly.
Look around you, you’ll find “unrestricted fields in a public-facing app” (from a practical perspective) everywhere. Shrek’s script has what, less than 50k characters? That’s nothing, you can fit that in a Facebook post and still have more than enough to write a full movie review.
Where this would likely raise flags is when somebody decided that it needs to be printed, but that could be a different team, maybe outsourced, maybe after the main app was developed, maybe it’s just some “plug-and-play” system that also handles bulk printing jobs, who knows.
I wasn’t really referring to this post with that question - though it is relevant that leaving even an effectively unconstrained field like one that allows for the shrek script to be submitted would have seen me fired (if it had somehow passed QC, field sizes are one of the first things checked).
I was more curious about how different our experiences seem to be: you seem to imply a background where you’re expected to take the requirements as gospel with what you write based solely off that unless you’re personally invested, whereas in my experience engaging critically with the project is the single most important aspect of the development process, and not questioning potentially unwanted behavior leaves you open to firing (or criminal neglect if you’re dealing with medical PII, criminal records, etc…)
I’m quite genuinely interested in the different approach to development philosophy you present here.
A more serious answer - it depends greatly on where I’m working and what we’re doing.
I’ve worked in places where we’d receive outsource work. Usually we’d get fairly detailed instructions about what to do and what to avoid, that were discussed between our PMs/architects and the client, including tests for example that were agreed upon. You were supposed to follow those to the letter, but the most important part was that you needed to deliver quickly because the customer wanted to keep costs to a minimum. “Useless questions” (from their perspective) were seriously frowned upon, so if it wasn’t specified, the expected approach was to do whatever was quicker.
This occasionally lead to situations where their QC/UATs would identify issues with their business rules, but as long as it was compliant with the requirements we received, it would then come back to be changed (at additional cost, depending on how big the change needed to be).
Once accepted though, job done, grab your next work item and move on. Months later they could run into a situation like the one in the printer and come back asking for a fix, but very likely that would go into the CR bucket and a quote would be provided.
Of course if you’re working for a company that actually cares about what they’re building, the philosophy is completely different. If I’m working on our products, then I build a good understanding of what I’m working on, and I’m expected to flag any concerns or issues I encounter even before it reaches QC.
That said, I’ve never heard of a developer ever being criminally charged other than intentional misconduct - like, in the world. Look at the IBM Queensland Health payroll system fiasco, I’m not sure anyone was even fired, let alone prosecuted.
Or even the Boeing 737-MAX crashes - how do you build a system that pitches the nose down repeatedly, without limitations? Those guys who worked on the MCAS software would 100% have considered a scenario where an angle-of-attack sensor would provide bad data, and the consequences of repeated trim, but alas - 2 planes crashed, 350 people died, and what are the consequences? Some payouts…
Yeah, sleepy and wasn’t thinking about file sizes. That 1Gb limit (or, the Tsql 65,536 * [something] limit) was what I was referring to, but rather obviously the plaintext script for the movie is a just a little tiny bit smaller than that (51kb).
It’s still a good deal larger than what in my experience can be fit into a receipt printer, but I can forgive their phrasing even if it was only a small part of the whole script. And aside from that, it does look to be a pretty modern device so it’s very possible that the stupid stupid 20kb file size limit that was so common has since been expanded (Last time I had to deal with a receipt printer the file was streamed over a serial connection into the printer cache before being run off G-code style. Incredibly charming piece of tech…)
Meh, not that hard to default things to “string”, or similar. For example, the “text” type in PostgreSQL explicitly says “unlimited”, though it seems it’s up to 1Gb. See https://www.postgresql.org/docs/current/datatype-character.html
Similarly, it’s not like text fields on web pages automagically apply limits.
It’s not unimaginable that some dumbass could vibe-code themselves up an easily exploited form.
100% accurate, though vibe coding is optional.
If I have a set of requirements that don’t mention any type of restriction, then I won’t arbitrarily add one - as far as I know, I could be breaking intended functionality. If I’m invested in this, I’ll add it to the list of stuff that needs clarification, otherwise it’s gonna ship as specified, and eventually someone’s gonna file a change request.
Sincere question, are you not expected to clarify questionable business rules? I’ve never worked somewhere that leaving such an obvious issue like “unrestricted fields in a public-facing application” without getting it explicitly stated that that’s intended functionality wouldn’t have gotten me fired instantly.
Look around you, you’ll find “unrestricted fields in a public-facing app” (from a practical perspective) everywhere. Shrek’s script has what, less than 50k characters? That’s nothing, you can fit that in a Facebook post and still have more than enough to write a full movie review.
Where this would likely raise flags is when somebody decided that it needs to be printed, but that could be a different team, maybe outsourced, maybe after the main app was developed, maybe it’s just some “plug-and-play” system that also handles bulk printing jobs, who knows.
I wasn’t really referring to this post with that question - though it is relevant that leaving even an effectively unconstrained field like one that allows for the shrek script to be submitted would have seen me fired (if it had somehow passed QC, field sizes are one of the first things checked).
I was more curious about how different our experiences seem to be: you seem to imply a background where you’re expected to take the requirements as gospel with what you write based solely off that unless you’re personally invested, whereas in my experience engaging critically with the project is the single most important aspect of the development process, and not questioning potentially unwanted behavior leaves you open to firing (or criminal neglect if you’re dealing with medical PII, criminal records, etc…)
I’m quite genuinely interested in the different approach to development philosophy you present here.
A more serious answer - it depends greatly on where I’m working and what we’re doing.
I’ve worked in places where we’d receive outsource work. Usually we’d get fairly detailed instructions about what to do and what to avoid, that were discussed between our PMs/architects and the client, including tests for example that were agreed upon. You were supposed to follow those to the letter, but the most important part was that you needed to deliver quickly because the customer wanted to keep costs to a minimum. “Useless questions” (from their perspective) were seriously frowned upon, so if it wasn’t specified, the expected approach was to do whatever was quicker.
This occasionally lead to situations where their QC/UATs would identify issues with their business rules, but as long as it was compliant with the requirements we received, it would then come back to be changed (at additional cost, depending on how big the change needed to be).
Once accepted though, job done, grab your next work item and move on. Months later they could run into a situation like the one in the printer and come back asking for a fix, but very likely that would go into the CR bucket and a quote would be provided.
Of course if you’re working for a company that actually cares about what they’re building, the philosophy is completely different. If I’m working on our products, then I build a good understanding of what I’m working on, and I’m expected to flag any concerns or issues I encounter even before it reaches QC.
That said, I’ve never heard of a developer ever being criminally charged other than intentional misconduct - like, in the world. Look at the IBM Queensland Health payroll system fiasco, I’m not sure anyone was even fired, let alone prosecuted.
Or even the Boeing 737-MAX crashes - how do you build a system that pitches the nose down repeatedly, without limitations? Those guys who worked on the MCAS software would 100% have considered a scenario where an angle-of-attack sensor would provide bad data, and the consequences of repeated trim, but alas - 2 planes crashed, 350 people died, and what are the consequences? Some payouts…
These ‘unlimited’ scams are getting out of hand. All I wanted was to store the library of alexandria in plain text.
Yeah, sleepy and wasn’t thinking about file sizes. That 1Gb limit (or, the Tsql 65,536 * [something] limit) was what I was referring to, but rather obviously the plaintext script for the movie is a just a little tiny bit smaller than that (51kb).
It’s still a good deal larger than what in my experience can be fit into a receipt printer, but I can forgive their phrasing even if it was only a small part of the whole script. And aside from that, it does look to be a pretty modern device so it’s very possible that the stupid stupid 20kb file size limit that was so common has since been expanded (Last time I had to deal with a receipt printer the file was streamed over a serial connection into the printer cache before being run off G-code style. Incredibly charming piece of tech…)