The art of developing a prototype
-
One of the developers is giving me a hard time now. We have a simple proto to be developed. Two modules, each having 3 screens. We just need 6 APIs altogether. 3 for each module. The developer is so stuck with the "CRUD" idea in mind. That he cannot resist developing all the Create, Read, Update, Delete & all the fancy REST operations Put, Patch. I just needed a Create API to populate the data. Nobody cares if the data is deletable or updateable. I just needed 3 APIs for the first module & then move on two the 2nd module. Now he's writing the 6th API for the *first module*, :doh: Validating and checking a lot of scenarios for update & delete. :sigh: Sometimes perfectionism is a curse.
Prototypes tend to become products. (Vaguely related: I was at G2E last year and one of the big vendors was showing what was clearly a prototype. But, they didn't even bother adding bogus data, so the presenter actually asked us to imagine the data being there.)
-
One of the developers is giving me a hard time now. We have a simple proto to be developed. Two modules, each having 3 screens. We just need 6 APIs altogether. 3 for each module. The developer is so stuck with the "CRUD" idea in mind. That he cannot resist developing all the Create, Read, Update, Delete & all the fancy REST operations Put, Patch. I just needed a Create API to populate the data. Nobody cares if the data is deletable or updateable. I just needed 3 APIs for the first module & then move on two the 2nd module. Now he's writing the 6th API for the *first module*, :doh: Validating and checking a lot of scenarios for update & delete. :sigh: Sometimes perfectionism is a curse.
Nand32 wrote:
I just needed a Create API to populate the data. Nobody cares if the data is deletable or updateable
And if it's not readable, you don't need to test the writeable part. Sounds perfect to me, since my code is always correct the first time, so no need to test it!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I'm sure they love it when you take their hacked together pretend data, discover that it actually works, and close their problem report as no-repro. :rolleyes: Seriously, unless your customer is the NSA or something similar, that's what NDAs are for. :doh: :doh: :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
How about the other way around, when I use software (let's say - some popular IDE) that is sold in the millions, and the vendor is too cheap to invest in proper QA and automated tests? Then, *every* *single* new minor version has some regression in it, and the vendor will not even look at a bug report that doesn't contain a whole bunch of logs and data that we cannot legally release to them. Also, in many cases a company wants to protect their users' personal information. Legality and regulations aside, this is the ETHICAL thing to. Wouldn't *you* be happy to know that your PII is treated with respect and that access to it is shared with the minimum number of people? Sure, it's frustrating to the vendor, and to the developers, and to me personally when I'm on the side that needs to fix bugs with limited information - but it is a fair price to pay for having an ecosystem that respects people's information and privacy.
-
Nand32 wrote:
Sometimes perfectionism is a curse.
That's not perfectionism, that simply a curse. Wasting time, effort and resources on something that is not in the scope of the project, even potentially introducing bugs with code that should not be there in the first place. throw new NotImplementedException();
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Nand32 wrote:
Sometimes perfectionism is a curse.
That's not perfectionism, that simply a curse. Wasting time, effort and resources on something that is not in the scope of the project, even potentially introducing bugs with code that should not be there in the first place. throw new NotImplementedException();
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
That's not perfectionism
That was my first thought. However, I disagree that the developer has a curse. Nand32 has the curse ... his developer. :-D
-
How about the other way around, when I use software (let's say - some popular IDE) that is sold in the millions, and the vendor is too cheap to invest in proper QA and automated tests? Then, *every* *single* new minor version has some regression in it, and the vendor will not even look at a bug report that doesn't contain a whole bunch of logs and data that we cannot legally release to them. Also, in many cases a company wants to protect their users' personal information. Legality and regulations aside, this is the ETHICAL thing to. Wouldn't *you* be happy to know that your PII is treated with respect and that access to it is shared with the minimum number of people? Sure, it's frustrating to the vendor, and to the developers, and to me personally when I'm on the side that needs to fix bugs with limited information - but it is a fair price to pay for having an ecosystem that respects people's information and privacy.
obeobe wrote:
an ecosystem that respects people's information and privacy
Occasionally that's the case, but most often it's far simpler. A number of our customers use our systems to print lottery tickets. Those folks almost never give us data, since they don't want us to print a winning ticket. The ones who print customized catalogs, account statements and the like won't share their data because they're worried about their competitors getting their customer list.
Software Zen:
delete this; -
Sounds like someone who's been burned one time too many when PHBs declared a prototype to be exactly what they needed and insisted on taking it directly into production.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Dan Neely wrote:
a prototype to be exactly what they needed and insisted on taking it directly into production.
Yes. If they can see it, it must be done! And that colleague that implements more than is asked for? It kind of makes sense to do it if it's going directly from demo to production. ;)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
One of the developers is giving me a hard time now. We have a simple proto to be developed. Two modules, each having 3 screens. We just need 6 APIs altogether. 3 for each module. The developer is so stuck with the "CRUD" idea in mind. That he cannot resist developing all the Create, Read, Update, Delete & all the fancy REST operations Put, Patch. I just needed a Create API to populate the data. Nobody cares if the data is deletable or updateable. I just needed 3 APIs for the first module & then move on two the 2nd module. Now he's writing the 6th API for the *first module*, :doh: Validating and checking a lot of scenarios for update & delete. :sigh: Sometimes perfectionism is a curse.
-
One of the developers is giving me a hard time now. We have a simple proto to be developed. Two modules, each having 3 screens. We just need 6 APIs altogether. 3 for each module. The developer is so stuck with the "CRUD" idea in mind. That he cannot resist developing all the Create, Read, Update, Delete & all the fancy REST operations Put, Patch. I just needed a Create API to populate the data. Nobody cares if the data is deletable or updateable. I just needed 3 APIs for the first module & then move on two the 2nd module. Now he's writing the 6th API for the *first module*, :doh: Validating and checking a lot of scenarios for update & delete. :sigh: Sometimes perfectionism is a curse.
I have to agree with the developer and I don't believe this is perfectionism. I have a distinct feeling this is experience and being burned a few times. The specifications you are providing, to me, don't sound fully flushed out and it sounds like there are a whole lot of truly unreasonable expectations of both people and the final system. I am left with two conclusions, either you are building a prototype to demo to reinforce the requirements, in which case the developer SHOULD NOT BE DEVELOPING, or you don't have a full understanding of how systems and people usually function and you need to be looking hard at your expectations. Call me a skeptic but your stated requirements break down like this, you have someone who wants to create data, never read it, will always input it correctly and always have whatever that data is follow through perfectly. That is what you are describing. From CRUD you are stating is that the data will only be created, well that means you don't need the read to verify the input was correct. You don't need the update because their data will always be input correctly the first time, and never need alteration. The data will always be followed through on (i.e. I have a store and every order ever placed will always be completed and never removed). Unfortunately, none of that sounds true. It sounds more like the specifications aren't fully flushed out and you are prototyping a product that is not whole. I have seen this, and I may not be exaggerating here, a million times but when you start the sentence off with I have this data, it literally means, I will tell you I don't need CRUD but in reality I do, I just don't realize it yet. I will the day before we launch. In nearly 20 years, I have yet to hear of a system that never needs all of the parts of CRUD. I have bumped into systems that don't need the delete part, but even those are rare.
-
One of the developers is giving me a hard time now. We have a simple proto to be developed. Two modules, each having 3 screens. We just need 6 APIs altogether. 3 for each module. The developer is so stuck with the "CRUD" idea in mind. That he cannot resist developing all the Create, Read, Update, Delete & all the fancy REST operations Put, Patch. I just needed a Create API to populate the data. Nobody cares if the data is deletable or updateable. I just needed 3 APIs for the first module & then move on two the 2nd module. Now he's writing the 6th API for the *first module*, :doh: Validating and checking a lot of scenarios for update & delete. :sigh: Sometimes perfectionism is a curse.
tell your boss, "Keep it simple, stupid." If he fires you, he did you a favor. :rolleyes: