views:

187

answers:

6
+2  Q: 

Proof of Concept

I need to provide a proof of concept to my boss. Our application is written in WPF, but I know Windows Forms back to front. Acheiving the POC in WPF is taking 3-4 times as long as it would in windows forms.

How would you go about this, either use WPF and get an ugly looking POC that takes thrice as long to create, or use windows forms and get a POC quickly that also will look ugly?

A: 

Software is an enabler to business. Business is when someone buys and uses you software and pays for it. As a software engineer the onus is on me to make a good software. If good means eye candy UI and will help makes the sales/pitch. I would do it. I would also make the timeline and submit it to my manager/boss. They by letting him make the call. If he says why can't you do it in less time, I would remind him of lack of expertise/know how/unfamiliar api. If the boss still can't understand it's his problem.

Ankur Gupta
He said his "boss", it's a different environment. He's not talking about making a personal sacrifice of time for the sake of his career and his clients - he's talking about a business environment where time weighs more than eye candy sometimes.
joshcomley
who decides whether the Ui looks good ? Customer or Boss or Developer. Certainly not the Developer.
Ankur Gupta
A: 

Depends on whether your workplace has a habit of making semi-working PoCs into the final application instead of treating them as the demo prototype that they are. I've seen people set up interactive PowerPoint presentations for GUI PoCs, or a storyboard, just to avoid this.

JeeBee
+1  A: 

As obvious as it sounds it's best to concentrate on proving the central idea of the concept beyond reasonable doubt as quickly and cheaply as possible.

If the essential idea behind the concept is “achieving manual data entry functionality in WPF” then obviously stick with WPF, if the central idea is GUI framework agnostic then go for WinForms.

Totophil
+5  A: 

It depends upon what you are trying to 'prove' with your proof-of-concept.

If the intent is to demonstrate that WPF is an awesome Rich UI platform, developing the PoC in Windows Forms would be detrimental to say the least.

If the intent is to demonstrate something that has no relevance to UI, it is not necessarily a bad thing.

In any case, it is always important to protect a PoC from being promoted to Product Code, so developing it in Windows Forms might have the added benefit that project managers would not feel the urge to reuse the PoC for the product app, if the product must be developed in WPF.

Mark Seemann
+1: This exactly the point: what is the goal of the PoC? Clarify it, and all details will come down easily.
Roberto Liffredo
+2  A: 

It depends. Do you have to proof that the problem can be solved within your product? Then use the same products to build it.

Otherwise, what is the risk of your Boss cancelling the project when he finds out that you used another framework? Does he believe you that it will really proof the thing can be implemented?

Will he fall for the user interface, or can he abstract it and look at the underlying problem?

Will he appreciate the time gained or is time no problem?

I would let him decide. He is the one paying for it.

Edit to react to comments: I hope that this thread would give a nice set of arguments to come to your boss with a well prepared suggestion, with risk analysis and all. Then, let him decide. If he is the kind of person that does not like to decide, do it for him then gently.

Ralph Rickenbach
"I would let him decide. He is the one paying for it." bang on.
Ankur Gupta
"I would let him decide. He is the one paying for it." — more frequently than not people pay to delegate decision making to experts: Don't discuss solution, discuss requirements (http://stackoverflow.com/questions/416779/when-the-client-asks-for-something-ludicrous-and-insists/423932#423932)
Totophil
On the other hand, he may be willing to pay for people to take decisions, not to dumbly follow orders.
Roberto Liffredo
Indeed, discuss requirements. But, all too often, "use this specific language" *is* a requirement.
Dave Sherohman
+1  A: 

Before you begin

  • define what it exactly is that you're trying to prove (UI look/feel? performance? some special functionality?)
  • implement the approach as graphically clean and simple as possible - keep the focus on what it is you're trying to show (if it's UI then sometimes simple wireframes in Powerpoint would work)
  • provide a list of assumptions and constraints - just because the POC works, you don't want to put yourself in the corner with the final delivery if you/your-boss have different assumptions
  • provide what you think are the actual business benefits to what you are doing...more then technical nice to have type of stuff
meade