Are there any Ruby on Rails whiz kids out there? I have a unique opportunity for someone that fits the bill. The compensation would be solely equity in a startup company that has had it's shares of ups and downs over the past 18 months.

I invested a significant amount of money in this company, based in Chapel Hill, about a year ago. It is a site that will uniquely cater to Foodies and independent restaurants and is quite a creative concept; I will be happy to more fully describe the company to qualified and interested people. Simply put, we have not been able to get the website fully functional as the current owners, investors and operators are not sufficiently "tech savvy" - I'm a business/finance person and have no experience in this area. We simply need a tech person that can move this over the finish line in exchange for some equity in the company. Most of the code has already been written and basically just needs some tinkering. This is a legit opportunity for the right person. I come to TWW because I know my fellow alums to be very talented, of an entrepreneurial spirit and local.

It simply comes down to this:

- we want to get the site up and running, even in a rudimentary version of our original plan in order to start generating revenue
- we have burned through too much cash paying 'contract' code writers to write the code that never got the site fully operational
- we need an entrepreneurial person with the technical expertise to help us finish without having to burn through more precious cash in the near term

Please contact me if you have Ruby on Rails experience and are interested in this opportunity. I don't care about age, sex, race, color, background, etc. If you can prove to me by work examples, resume, etc. that you have the talent and ability, then I want to chat with you.

I will be happy to chat about the situation in further detail and answer any questions that you may have. Shoot me a pm with your info and I'll get back to you re: an initial chat.

Thanks in advance.

1/22/2009 2:57:33 PM

i would be willing to help for 40% equity and complete ownership of the code.

1/22/2009 3:11:00 PM

Again, most of the code is already written. 40% is high but not too far off of what we could do for the IDEAL person. This is a legit opportunity; if you're interested and qualified PM me and we can chat.

1/22/2009 3:37:27 PM

thank-you to the unnamed user who sent me this PM:

Quote :

"regarding your rails job... i personally cannot help as i'm employed so any code i write is not owned by me. but i thought i'd offer some insight what other programmers see when they read your thread: -we paid other people a lot of money -what they delivered still doesn't work -we have high hopes that it's almost there, and that it wouldn't take much more work. what other programmers think when they read your thread: -why did you pay contractors for something that didn't work? -were the requirements not clearly defined, or did the client keep changing them? (e.g. oh you want a new feature? it'll cost you) -we know that it doesn't work, and you've said you aren't very technically adept, how do you know it's nearly working? it's either working or not working."

I will try and answer these. We used contract programmers on a part-time, hourly basis. The more cash we burnt through, the more we noticed that the programmers weren't delivering us a final product and it was becoming too expensive. This was a mistake by our company; in hindsight, we should have probably gone with a professional firm and gotten a fixed quote for a certain product. We thought it'd be cheaper to go the other route. This obviously didn't pan out well.

The reason I know that the site works SOMEWHAT is that I have seen the site up and running; only to a limited extent. We still need some of extra 'tools' to be added and for them to be running smoothly. It is not, however, the final product that we envision offering to a customer in order to start generating revenue.

[Edited on January 22, 2009 at 7:20 PM. Reason : quote]

[Edited on January 22, 2009 at 7:23 PM. Reason : ;]

1/22/2009 7:20:36 PM

Here's the problem.

You don't have a spec. The likelihood that your product is "almost there" ranges from slim to none. There's a very very good chance that any ideal candidate is going to review the code and infrastructure that you have, and recommend starting over.

Unfortunately for you and your business partners, you followed the absolute worst development path possible. You neglected to go through the Requirements and Specifications process to detail out the expected capabilities and the deliverables to get those capabilities. Then you threw money at code, rather than planning. Now you have lots of code, but still no plan.

I would make two recommendations:

1) You are a software service company. You damn well better understand software development. Understanding the process and understanding code are two entirely different things. Go purchase, check out, or borrow a book on Agile Development using the SCRUM model. You do not need another developer, you need a system architect/project manager.

2) Once you have a well-written, comprehensive specification, development timeline, cost estimation and deliverable outline, THEN you can go find a knowledgeable Ruby developer to help you sort through the code you have to determine how much of it is actually usable to achieve your short and long-term goals.

1/22/2009 7:45:28 PM

Noen: I appreciate your input, but I can guarantee you that the site is very close to being fully functional and the code is usable. Again, it was up and functional for the most part, we just had some extra tools that were going to come with subsequent releases that weren't there yet.

Also, we did have a system architecture plan done by a professional firm. We need someone to get us there and then we'll obviously need someone to stay on while the site is up and running - but we can worry about the latter once we're close to having the site operational.

I'd love to find someone who is entrepreneurial and can find solutions - no matter what - not problems.

1/23/2009 8:51:25 AM

trust me dude, noen knows more about your site than you do

1/23/2009 10:37:47 AM

lulz

1/23/2009 10:49:41 AM

switching people mid stream is rarely a good idea unless they are just screwing you over - the amount of time it takes someone to get up to speed (rarely will you not get billed for this) and learn the code can be significant

the way most developers will be (it's already been said even) is that they will want to start fresh - especially if they are going to be the one maintaining the code

1/23/2009 10:55:08 AM

Quote :

"Also, we did have a system architecture plan done by a professional firm."

If that's the case, why have you been hiring contractors hourly, instead of by deliverable?

^Totally Agree.

1/23/2009 11:39:07 AM

Quote :

"Go purchase, check out, or borrow a book on Agile Development using the SCRUM model"

Agile Development yes, SCRUM, not so much. He will likely only have one developer, not a team of 5-15. A "SCRUM" of 2 people is a face-to-face meeting, I guess you could integrate questions used in a typical SCRUM... though all you'd really need to ask the developer is What have you done since yesterday? What are you planning to do by today? Do you have any problems preventing you from accomplishing your goal? There's plenty of books on Iterative Project Management, probably even a Dummies one by now.


[Edited on January 23, 2009 at 12:09 PM. Reason : a]

1/23/2009 11:54:12 AM

Quote :

"Once you have a well-written, comprehensive specification"

wrong way to approach software development. the fact that you mentioned and even bolded Agile Development using the SCRUM model makes me wonder why you would even say this. Agile Development is about ITERATIVE development. spending time to prepare comprehensive specification will be a complete waste of time and a month down the road, it will be obsolete and nobody will even read it

[Edited on January 23, 2009 at 12:49 PM. Reason : .]

1/23/2009 12:43:36 PM

He was clearly not talking about a Technical Spec but a Functional Spec which shouldn't be iterative through the development of a project. If the client requirements are changing then there are bigger problems to address then which development style is being used.

1/23/2009 1:03:38 PM

hmmm, i didn't read it as clearly being a functional spec, but i can see that. and while i agree knowing what you want upfront IS necessary for a successful project (at least moreso than how you're going to do it upfront), i think changing client requirements are gonna happen just as much as technical requirements are going to change. for instance, the company my team is doing work for now, when they came to us they had a 50 page document (that took them 2 years to make) detailing all the screens they wanted, etc. it was still garbage. we spent 2 weeks building functional mockups of their specs, and uncovered what would have been another 50 pages in documentation. in the 9 months we've been here, we are light years beyond where their vision started and have been the only team on time or ahead of time since, because we told them we were gonna use Agile and do it our way. everybody else is steeped in waterfall and ms project and wasted time and money. they've been so impressed with our results they even renamed their product Agile ( ) i've seen it time and time again. people don't really know what they want until they see it. that's why even for functional requirements, an iterative approach is still helpful. implement the highest business value features known at the time, evaluate the result, implement the highest business value features known at the time (even if it's modifications to what you just built), evaluate the result, repeat, repeat. beats the hell out of spending 3 months planning a 12 month project, just to see market conditions change 6 weeks into implementation and now you need different software. you gonna spend another 3 months replanning?

[Edited on January 23, 2009 at 1:32 PM. Reason : i could ramble about this stuff all day ]

1/23/2009 1:22:08 PM

hell we'd do it, but yeah we'd probably just start from scratch.

1/23/2009 1:30:23 PM

You could ramble on about it all day. Become a PMP and teach as a contractor on the side

1/23/2009 1:32:20 PM

you're right. our scrum leader just took a job with http://www.netobjectives.com/ and we are probably going to be doing technical training for companies trying to implement agile

1/23/2009 1:34:17 PM

Quote :

"they've been so impressed with our results they even renamed their product Agile "

lool

1/23/2009 1:36:19 PM

^^I have all of the courseware available if the does not have his own

http://www.evanetics.com/Training.htm

^haha I missed that.

[Edited on January 23, 2009 at 1:39 PM. Reason : s]

1/23/2009 1:36:53 PM

agile development is where you churn out shit code really fast, move on to something new, and ignore anyone who complains about the old stuff.

[Edited on January 23, 2009 at 1:56 PM. Reason : ,]

1/23/2009 1:56:11 PM

Quote :

"everybody else is steeped in waterfall"

eh, I like the agile approach from the 10,000' view
and then taking a waterfall approach to each individual/tangible building block as you implement it (or atleast an abbreviated waterfall, all those steps can be cumbersome)

1/23/2009 3:07:28 PM

I have no idea what any of you are saying but it seems I at least came to the right place. I've had some responses but am still open to chatting with the right person (people). Thanks.

1/23/2009 3:21:48 PM

^ They're saying your spec is irrelevant and you don't know what you want.

And they're arguing if the best approach is for you to develop a full spec all at once, and have someone try and implement it, or to just tell them a general idea of what you want, have them take a whack at it, see if you like it, then make modifications as necessary (ie the iterative approach). I'm not sure what waterfalls have to do with it though...

IOW, they aren't really discussing your problem anymore

1/23/2009 4:22:14 PM

Quote :

"The more cash we burnt through, the more we noticed that the programmers weren't delivering us a final product and it was becoming too expensive."

The Iterative approach they are discussing would have defined steps/benchmarks/checkpoints that would need to be reached in a defined period of time/money before the next steps were taken. You don't move on til everything you have done before is correct and you can go back and fix stuff later if needed.

[Edited on January 23, 2009 at 4:51 PM. Reason : a]

1/23/2009 4:49:38 PM

It sounds like they started with a fairly formal waterfall process, but waterfall development almost requires a consistent, stable development team. At least with an agile environment you can switch off development duties from one iteration to another, but you still need some stability in your development staff.

And qntmfred: It was very valuable to ask the question you did, I was definitely talking about a functional specification (and even then, really talking about it on the level of Pillars/User Stories/Key Investments). I totally agree that heavy spec-writing is seemingly always throw-away work.

But you can do good envisioning functional specs FAST, and they are also very easily adapted as a product continues evolving. Waterfall as a process is all but dead in real business. It's been pretty well replaced by formal iterative processes (CMMI for instance).

1/23/2009 6:13:15 PM

Quote :

"the way most developers will be (it's already been said even) is that they will want to start fresh - especially if they are going to be the one maintaining the code"

why do most companies NOT understand this? *sigh*

1/23/2009 7:16:40 PM

Scrum: not an acronym.

1/23/2009 7:46:07 PM

CAN I GET A D-T?!

1/23/2009 8:09:33 PM

DONALD


THOMPSON


?

1/23/2009 8:13:23 PM

he tried to facebook friend me lol

1/23/2009 8:24:59 PM

Yeah for a while there they were all up on some facebook.

I friended them, I don't give a fuck dogg.

1/23/2009 8:49:25 PM

you probably never cussed him out or put a copy of Brooks on his desk either

1/23/2009 8:55:39 PM

No

1/23/2009 9:06:52 PM

Quote :

"It sounds like they started with a fairly formal waterfall process, but waterfall development almost requires a consistent, stable development team. At least with an agile environment you can switch off development duties from one iteration to another, but you still need some stability in your development staff. "

The choice of using different methodologies (waterfall, spiral, agile, etc) depends on whether the requirements are well known or not, waterfall assumes perfect knowledge, and if you are using a stable technology with well known requirements (usually enhancements), waterfall makes sense.

The agile approach assumes you don't have perfect knowledge or dealing with uncharted territory. Do iterations of prototypes and demonstration until you have traceability from the final specs back to the business reqs. Given that the poster stated that it is a "creative concept" I'd say agile would make sense.

1/23/2009 9:13:55 PM

Quote :

"The reason I know that the site works SOMEWHAT is that I have seen the site up and running; only to a limited extent. We still need some of extra 'tools' to be added and for them to be running smoothly."

So you just need the other 95% of the site finished?

1/23/2009 9:49:48 PM

Quote :

"why do most companies NOT understand this?"

That doesn't immediately make the most business sense, and is hard to articulate to business people. (though as a technologist, that is almost always the preferred method, only not so if its built on a clear framework with good documentation - lol)


and this thread makes me laugh

1/24/2009 1:57:50 AM

Quote :

"The choice of using different methodologies (waterfall, spiral, agile, etc) depends on whether the requirements are well known or not, waterfall assumes perfect knowledge, and if you are using a stable technology with well known requirements (usually enhancements), waterfall makes sense. The agile approach assumes you don't have perfect knowledge or dealing with uncharted territory. Do iterations of prototypes and demonstration until you have traceability from the final specs back to the business reqs. Given that the poster stated that it is a "creative concept" I'd say agile would make sense."

That's what they tell you in school. The reality of being a sales driven software company is that pretty much all development devolves into your definition of an agile bucket.

These days, only contract consultants and outsourced development can still really use waterfall even somewhat effectively.

Quote :

"why do most companies NOT understand this? *sigh*"

Because most companies have absolutely no idea what they are getting into with software development. I learn this lesson more and more every day

1/24/2009 2:25:43 AM

Quote :

"Because most companies have absolutely no idea what they are getting into with software development. I learn this lesson more and more every day "

You should be happy about this: it's called job security.

Believe me when I tell you that I'd rather dig ditches than do what you guys do - I'm glad there are people that are out there that enjoy it though; I sure as hell don't.

1/24/2009 5:57:52 PM

^yeah, aren't professions amazing? i hear there are people who enjoy reading legalese, and people who don't faint at the sight of blood too.

1/25/2009 3:42:03 PM

Well agile is still new territory to most companies (probably ~10% do agile), a lot of companies favor spiral over waterfall since it's a hybrid form of iterative design and development with waterfall. Even with any methodology, most projects are still miss their on-time and budget baselines. IMO the situation the poster described sounds like poor project management than anything else.

There's like two companies that I know can do 3PM well (Project, Program & Portfolio Mgmt), that's Microsoft and IBM.

1/26/2009 1:27:51 AM