The art of developing a prototype
-
once worked for a boss who would be a perfect match to your man, this bosses concept of a POC was something that had *full functionality* to be "demonstrated on a subset/sample of the data." Seriously, one project was: "OK team, we got a potential 5 - 6 month project to develop a package to do account consolidation using 'fuzzy logic account matching' on 60 million records from 3 different systems, we need a POC / demo system to do ALL of those things on a 6000 record sample for a meeting with them next week. We're flying in for the demo next Friday and by the way it has to be on their hardware because they can't release any data [privacy bullshit] even for testing." I magnanimously offered myself for the role of preparing the powerpoint slides for that meeting. :)
Message Signature (Click to edit ->)
-
It seems that most every time I have ever delivered a POC or mockup, even after explaining that 'these screens aren't wired yet', someone inevitably complains that they can't save their input. :doh: I agree that its overkill for a proto, but hard to argue with someone doing more than required...just at the wrong time.
"Go forth into the source" - Neal Morse
-
Bingo! My boss should read this. He exactly has this (sly) behaviour of trying to push a proto into production. But we push him back explaining why that wouldn't work. But this developer who is doing this genuine proto is just crazy. lol :)
Nand32 wrote:
My boss should read this. He exactly has this (sly) behaviour of trying to push a proto into production
Tell the boss the prototype has a bug that can delete half of the data randomly, and nobody knows why, so while it's okay as a prototype, it *cannot* leave a test environment.
-
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
So true, this was the first thing which came to my mind as well since it has happened so frequently. The other alternative is when the customer sees the prototype and is frustrated that it isn't a fully functional program they can start using tomorrow. :sigh:
-
once worked for a boss who would be a perfect match to your man, this bosses concept of a POC was something that had *full functionality* to be "demonstrated on a subset/sample of the data." Seriously, one project was: "OK team, we got a potential 5 - 6 month project to develop a package to do account consolidation using 'fuzzy logic account matching' on 60 million records from 3 different systems, we need a POC / demo system to do ALL of those things on a 6000 record sample for a meeting with them next week. We're flying in for the demo next Friday and by the way it has to be on their hardware because they can't release any data [privacy bullshit] even for testing." I magnanimously offered myself for the role of preparing the powerpoint slides for that meeting. :)
Message Signature (Click to edit ->)
Lopatir wrote:
they can't release any data [privacy bullshit] even for testing
Been there, done that so many, many times. We build commercial inkjet printing systems. I've lost track the number of times a customer has complained of a printing problem, we've asked them to send us their data, and one of two things happen. They either outright refuse, or they send us "pretend" data that was hacked together by hand. We're still supposed to fix their problem, though :suss:.
Software Zen:
delete this; -
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 can't help but think that three years down the line you'll be thanking the invisible pink unicorn that he went to all that trouble.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Lopatir wrote:
they can't release any data [privacy bullshit] even for testing
Been there, done that so many, many times. We build commercial inkjet printing systems. I've lost track the number of times a customer has complained of a printing problem, we've asked them to send us their data, and one of two things happen. They either outright refuse, or they send us "pretend" data that was hacked together by hand. We're still supposed to fix their problem, though :suss:.
Software Zen:
delete this;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
-
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.
One very useful skill to have is an understanding of what to leave out of a POC. I always try to omit at least one key thing that prohibits the POC from going immediately into production. Otherwise there is strong possibility that it might. You can easily find a whole new set of problems dropped in your lap when that happens and, of course, they have to be fixed immediately since the POC is in production.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
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.
:laugh: I have an application (classbuilder) that writes all 3 levels of the CRUD code in about 30 seconds for each table/view. Stored proc, API or WCF, client data service and controller if required and even some of the WPF views. I used to specialise in POC and most went straight to production with only the custom processing required.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
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: