>> The only advice I've got is to do things in increments as small as
>> possible. Don't do "big bang" integration. Make sure there is a
>> runnable testable program after the first week of development. Maybe
>> it doesn't implement any significant features, but you must have
>> something runnabl
* Grant Edwards wrote:
> The only advice I've got is to do things in increments as small as
> possible. Don't do "big bang" integration. Make sure there is a
> runnable testable program after the first week of development. Maybe
> it doesn't implement any significant features, but you must have
On Saturday 13 November 2010, Grant wrote:
> I don't need encouragement, I need advice. :)
In the end it isn't a technical problem, it is a question of trust.
> > The questions are:
> >
> > 1) The relative sizes of the problems?
>
> No problems really. It's just kind of a never-ending project
>> Great advice from everyone, thank you. By hiring coders, the
>> intention is to save myself time and effort but it sounds like I would
>> only be replacing one problem with another.
>
> I hope I wasn't too discouraging, but you're definitely replacing one
> problem with another.
I don't need e
On 2010-11-13, Grant wrote:
Have you ever managed a programming team before?
>>>
>>> I haven't. ?Any pointers?
>>
>> Not really. ?Just be prepared for the programmers to misunderstand the
>> specification at every turn. ?And once they've understood the spec, be
>> prepared for them to just p
Should I only hire coders I can sit in the same room with?
>>>
>>> That will probably work best, but it will cost more.
>>>
>>> Have you ever managed a programming team before?
>>
>> I haven't. Any pointers?
>
> Not really. Just be prepared for the programmers to misunderstand the
> specific
On 11/09/2010 06:52 AM, Grant wrote:
This is OT, but you guys have proven extremely insightful over the
years and I would love to hear what you think.
I've been working on a particular software project for a long time.
I'd like to hire a team of developers to take over the project, but I
conside
On 2010-11-11, Grant wrote:
>>> Should I only hire coders I can sit in the same room with?
>>
>> That will probably work best, but it will cost more.
>>
>> Have you ever managed a programming team before?
>
> I haven't. Any pointers?
Not really. Just be prepared for the programmers to misunder
On Thursday 11 November 2010 17:33:25 Grant wrote:
> > Have you ever managed a programming team before?
>
> I haven't. Any pointers?
Good grief! The literature is full of weighty tomes on the subject, and
copious advice is available in multiple news groups - and no doubt e-
mail lists too by n
>>> Grant, you need to stop being paranoid. ?I am surprised you even
>>> worked up the courage to let slip on here, in public, that you even
>>> have a sooper dooper sekrit project.
>>
>> This seems to be the general consensus. You see, I don't have a
>> computer science degree and about 75% of wh
On 2010-11-11, Grant wrote:
>> Grant, you need to stop being paranoid. ?I am surprised you even
>> worked up the courage to let slip on here, in public, that you even
>> have a sooper dooper sekrit project.
>
> This seems to be the general consensus. You see, I don't have a
> computer science deg
Am 10.11.2010 06:56, schrieb Grant Edwards:
> On 2010-11-09, Florian Philipp wrote:
>
>> Well, there are two ways to go here:
>
>> 1. Modularize what you have. Give every developer only the source he
>>is supposed to work on and binary interfaces (libs + header files
>>for C/C++) and doc
On 2010-11-09, Mark Knecht wrote:
>> I don't mind system administration but I don't want to be a programmer
>> any more. ??I'd like to hire programmers to work in the manner
>> described above. ??They would each work on modules and not know about
>> the system as a whole. ??How can something like
On 2010-11-09, Florian Philipp wrote:
> Well, there are two ways to go here:
> 1. Modularize what you have. Give every developer only the source he
>is supposed to work on and binary interfaces (libs + header files
>for C/C++) and documentation for everything else.
>
>Then the devs w
On 2010-11-09, Grant wrote:
>> So is your question really "how do I modularize my code"?
>
> I'm most interested in the part about developers not knowing about
> the system as a whole. I'd like developers to work on my code, but
> prevent them from selling the code or using it themselves.
Have
Am 09.11.2010 19:08, schrieb Grant:
>>> "Theoretically, a modularized software project will be more easily
>>> assembled by large teams, since no team members are creating the whole
>>> system, or even need to know about the system as a whole. They can
>>> focus just on the assigned smaller task."
Apparently, though unproven, at 20:08 on Tuesday 09 November 2010, Grant did
opine thusly:
> It sounds like I'm really going against the grain here. Is it
> standard practice to hire a developer on the internet from any given
> country, never meet him or her, have them fax a signed NDA, and turn
On 9 November 2010 10:08, Grant wrote:
> It sounds like I'm really going against the grain here. Is it
> standard practice to hire a developer on the internet from any given
> country, never meet him or her, have them fax a signed NDA, and turn
> over your biggest asset to them?
:-) No way. :-)
Only expose the teams to what they need, give them prototypes and
discriptions to the other parts. Like a man page.
On Nov 9, 2010 12:16 PM, "Grant" wrote:
>> Read the OP again. He wants to obsfuscate the code to make it
>> unreadable for the people he's hiring to work on it.
>>
>> It would be si
On Tue, Nov 9, 2010 at 9:14 AM, Grant wrote:
>> Read the OP again. He wants to obsfuscate the code to make it
>> unreadable for the people he's hiring to work on it.
>>
>> It would be simpler and cheaper to hire developers who don't
>> understand programming language in question, computers, progr
>> "Theoretically, a modularized software project will be more easily
>> assembled by large teams, since no team members are creating the whole
>> system, or even need to know about the system as a whole. They can
>> focus just on the assigned smaller task."
>>
>> http://en.wikipedia.org/wiki/Modul
On 9 November 2010 09:14, Grant wrote:
> "Theoretically, a modularized software project will be more easily
> assembled by large teams, since no team members are creating the whole
> system, or even need to know about the system as a whole. They can
> focus just on the assigned smaller task."
>
>
> Read the OP again. He wants to obsfuscate the code to make it
> unreadable for the people he's hiring to work on it.
>
> It would be simpler and cheaper to hire developers who don't
> understand programming language in question, computers, programming in
> general, or even english.
>
> Then don'
On 2010-11-09, Florian Philipp wrote:
> Am 09.11.2010 05:52, schrieb Grant:
>> This is OT, but you guys have proven extremely insightful over the
>> years and I would love to hear what you think.
>>
>> I've been working on a particular software project for a long time.
>> I'd like to hire a team
24 matches
Mail list logo
