Language:
switch to room list switch to menu My folders
Go to page: First ... 7 8 9 10 [11] 12 13 14 15 ... Last
[#] Thu Feb 10 2011 13:02:59 EST from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've not had any experience with SCRUM, but I can speak about hardware development, having worked closely with the hardware development teams on a number of projects.

Hardware guys tend to like firm dates because those dates can have an impact on the overall development cost. Parts availability, scheduling time with a manufacturing group (easier when it's not outsourced), having resources available to do design, schematics, layout, signal integrity, and, when prototypes become available, device verification testing (DVT). If a date is too early, an integral part may not be ready in time, forcing the choice of a more expensive or substandard part from another vendor (which may require pre-qualification to meet your company's standards). If the date is too late, hardware may be ready early, but that's wasted cycles that could've been spent working on another project.

In situations like these, it can be helpful to contact the hardware vendors and ask them if they can supply reference samples. For example, you can get reference evaluation boards from CPU vendors. It may not match the target hardware, but it may be enough to allow you to do early code bring-up before prototypes become available. Emulation tools can also be very handy for early coding and simple functional verification.

Another possibility, though it may difficult, depending on your company's standards, vendor agreements, etc, is to go with a vendor that has already done some of the software legwork by providing an SDK. This will be more true of chipset vendors than it will be for discrete parts, but it never hurts to ask.
Hardware Binder

[#] Thu Feb 10 2011 23:21:27 EST from isoroku @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Yeah, I always try to keep that in mind. I'm trying to convince them they don't need the whole testing suite ready to start some of their verification testing.

[#] Fri Feb 11 2011 13:18:32 EST from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's definitely a good idea. Our hardware guys here usually only ask that software be ready enough to allow them to do some simple traffic tests. That can usually be accomplished within schedule by providing a special diagnostics-only version of the code, which takes a lot less effort than getting the whole system running.

[#] Fri Feb 11 2011 14:05:26 EST from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Attempting to convince our IT department at work that Citadel is a better replacement for M$Exchange than using Google Business e-mail solutions.....



[#] Sun Feb 13 2011 22:59:46 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Are any of you other software folks using Scrum for your development
process?

I think they make a topical cream for that.

[#] Mon Feb 14 2011 23:32:24 EST from isoroku @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Heh, I kind of expected that type of comment from someone.

[#] Wed Feb 16 2011 15:12:49 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Are any of you other software folks using Scrum for your development

Sorry unrelated but everytime somebody says "scrum" I have to say "sounds like something you scrape off the bottom of your balls."

[#] Wed Feb 16 2011 17:03:04 EST from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

My attempts at convincing our IT department to switch to Citadel were futile. They've decided to go ahead with Google solutions because of their wider range of colorful apps.

sorry folks, tried to get Citadel into a larger corporation, but didn't happen.



[#] Wed Feb 16 2011 21:59:48 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's ok ... I'm fine with letting Microsoft and Google fight over the "enterprise" market. We're going after the smaller orgs that they're leaving behind.

[#] Wed Feb 16 2011 23:27:07 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

ahhh, ig beat me to it, I didn't see right away.

[#] Tue Feb 22 2011 12:50:14 EST from skpacman @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

 


We're going after the smaller orgs that they're leaving behind.

which is exactly why I use citadel for Blurred Vizion Studios' email and groupware.



[#] Wed Mar 02 2011 12:12:45 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I appear to be working with voodoo code.

The vendor helpfully provides these nice example sources so you can play with their hardware and figure out how to make it do what you need it to do.

In their example code, I see something like this (where the variables are 'int' variable types):

FrameWidth = 1920;

FrameHeight = 1080;

When I stream the values of these variables to std::cout, FrameWidth shows as 780, and FrameHeight shows as 430... even after they were set immediately before streaming the values to std::cout, with no intervening commands that could change those values.

I have to believe there's a logical explaination for this, but at the moment, I'm at a loss.  It looks like voodoo code.



[#] Wed Mar 02 2011 13:13:07 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I found my logical explaination.

1080 is 0x483.  The stream was still displaying numbers as hexidecimal from an earlier setting.  So the number wasn't different after all, just the display of it.



[#] Wed Mar 02 2011 23:07:02 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I have to believe there's a logical explaination for this, but at the
moment, I'm at a loss.  It looks like voodoo code.

Another thread is playing with it?

[#] Thu Mar 03 2011 15:28:56 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

No, something dumber.

std::cout << "Display this as hex: " << std::hex << variable_with_some_huge_number << std::endl;

std::cout << "Display this as dec: " << 1080 << std::endl;

The second line will display as hex unless you do:

std::cout << "Display this as dec: " << std::dec << 1080 << std::endl;



[#] Thu Mar 03 2011 15:29:37 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

By 'dumber', I mean I was stupid.  I should have remembered that the std::hex thing would stick to the thread until I cancelled it with std::dec.



[#] Thu Mar 03 2011 15:29:49 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Grr... not 'thread', but 'stream'.



[#] Fri Mar 04 2011 13:28:37 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I have to believe there's a logical explaination for this, but at the
moment, I'm at a loss.  It looks like voodoo code.

Since when is "voodoo" not a logical explanation for something?

After all the nonsense that goes on in the workplace, why not throw voodoo on the pile?

[#] Fri Mar 04 2011 15:10:49 EST from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think it's more sensible to keep voodoo out of the workplace.

You would NOT want me to write up a test plan for voodoo. It would not be pretty.

[#] Sat Mar 05 2011 07:35:29 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I knew of one company who seemed somewhat convinced that we wrote voodoo code.  They didn't really believe that we could do all the things we said we could do.



Go to page: First ... 7 8 9 10 [11] 12 13 14 15 ... Last