|
Courage? What does it take?
During these years as a software developer I realized there is something missing. I'm not
talking about the grand scheme of things. I simply realized there is a tool that, if
developed right, would fit like a glove to a certain niche. I believe this is such a good
idea that I'm not saying what product is to keep the competition away.
But some things plague me. I have never developed shrinkwrap software. I don't know what would
take to develop and test such an application. For this to work it would have to be
developed in VC++ (the best performing language on Windows, AFAIK). Speed is crucial. I'm mostly a Java guy with some Swing and lot's of EJB. The product itself is pretty complex, and it would require a strong knowledge of databases, especially a certain vendor, and that is something I am not an expert at.
Hell, I don't even know where to start. Now I come to realize: I have the idea, I believe I
have the niche but I don't have the tools or the know-how.
And how do I keep the long term vision, the motivation to work on this until revenue eventually starts to flow?
Any pointers on how to make this go ahead?
RP
Sunday, April 11, 2004
>> Speed is crucial.
VB for the interface, PB/DLL for the number crunching. I doubt you'll find any tool that'll let you be as productive, and not worry about dangling pointers and buffer overflows :-)
My E.20
Fred
Sunday, April 11, 2004
>> Any pointers on how to make this go ahead?
I don't think you're exactly asking about courage. You're trying to figure out how to execute your idea.
If you're currently working and have an income, may I make a suggestion based upon what you're saying. And I am serious.
Define segments of your project and sub out the implementation work, in C++ or whatever, on rentacoder.com. Define segments of work that don't reveal the intent of the entire project.
A benefit of the subbing-out model is that you would be forced to engineer your entire concept from start to finish and you would have to divide your concept into functional areas.
A variant would be to sub out the development of performance critical sections in a compiled language, while you would develop the "shell", the user interface, and/or the main application.
The reason I say this is that you're admitting that you don't currently know a language that would allow you to develop an entire redistributable product.
Bored Bystander
Sunday, April 11, 2004
Prototype the thing in C# - it's close enough to Java that you should be able to pick it up pretty quickly, and the Visual Studio IDE will help you with your dev time.
If you really need microsecond gains, refactor the areas that need it into C++ (or even assembly language?)
You vaguely mention needing to understand the platform and databases and intricacy - unless you're thinking of a vendor-specific niche, I'd have to push SQL Server/Analysis services over PowerBuilder - both for ease of development and ease of understanding.
If you do sub out parts of the project, be sure to sub out parts that don't represent the whole, so you don't find yourself undercut in the market (this applies whether you sub locally or overseas).
[Yes, I'm wearing my Microsoft hat now, but I honestly believe in the time-to-market differentiators of our tools]
Philo
Philo
Sunday, April 11, 2004
I might suggest to take a step back and assess your business skills or entreprenurial zeal before your technical abilities.
Not to sound harsh, but ideas are largely worthless. It's the ability to execute an idea that separates people. I'll go further and suggest that if your idea is destined for profitability, then it probably isn't novel: There are probably several people with the same idea right now.
Don't be discouraged. As I said before, the ability to see an idea through profitable fruition is beyond most people so even if someone else has the same idea that you do, they might not be able to make it happen.
Eric Sink made a great book recommendation a while back that is a wonderful book for budding entrepreneurs. It's called "You Need to Be a Little Crazy : The Truth about Starting and Growing Your Business" by Barry Moltz. It's an easy book to read and offers some home-spun advice from someone who has both failed and succeeded in business.
Mark Hoffman
Sunday, April 11, 2004
> > I don't think you're exactly asking about courage. You're trying to figure out how to execute your idea.
That is absolutely right. I don't know where to begin and I am afraid to begin. What if it doesn't make any sense at all?
This seems to be such a huge undertaking that it makes my head go round. Are there any books? Articles? Websites?
Something to help me go along the way.
RP
Sunday, April 11, 2004
Philo:
The thing must be done in C++. My experience tells me that Java or C# simply aren't up to snuff in terms of performance. We're talking about some very very heavy number crunching here.
RP
Sunday, April 11, 2004
RP, the number crunching isn't in the entire application, is it? You prototype in C#, then once you've got it working the way you want it, you refactor libraries in C++ as necessary.
Or, if you're crunching data, you look at Analysis Services to see if that makes more sense.
However, I'm going to take this all back now and agree with Mark - you're looking at a business proposition, and the first step in any business is a business plan...
Philo
Philo
Sunday, April 11, 2004
Usually, I'm the first to be a performance bigot, since I
work on small, embedded systems where everything's
slow, sloppy programming is punished harshly, and the
classic "just buy a faster CPU and more memory" fix isn't
relevant.
But in this case, designing your app
using a scripting language to prototype makes sense; you'll
get a feel for the UI and can work out issues with your
algorithm with small datasets, and if you're looking for
funding or customers, you'll have something to demo.
(This is good both for improving your UI as well as
showing some "meat" as opposed to slideware.)
If you get funded or otherwise feel confident in going
forward, figure out the slow parts and recode those in C++.
(Note: db's are slow enough that recoding db interactor
code in C++ won't help so much. Number-crunching is
another story.)
x
Sunday, April 11, 2004
Yes, number crunching is another completely different thing and I expressed myself the wrong way back there.
What I mean is, this app must take as little memory as possible. I've developed in both Visual Basic and PowerBuilder, excelent languages when you want to write db driven apps, and both deliver an exceedingly big executable. And performance isn't that good when you have tons of thousands of records being dumped on you.
RP
Sunday, April 11, 2004
Dude, with all due respect, you're talking all over the place. "Must use as little memory as possible" but "having thousands of records dumped on you"?
"Thousands"? That's absolutely nothing in modern terms. I'll wager most senior programmers on JoS use thousands of records as test sets.
Once again, I suggest you slow down, take a deep breath, and start drafting a business plan, then start working on your requirements. You've got a ways to go before you have to worry about what platform.
Best of luck!
Philo
Philo
Sunday, April 11, 2004
Oops - missed the "tons"
But my last statements still apply. :)
Philo
Philo
Sunday, April 11, 2004
On the performance issue, the work I do involves heavy number crunching. As I'm a researcher (I'm not developing shrink-wrap), I use Matlab*, which is a very complete environment for the kind of work I do. It relies on BLAS and LAPACK for its matrix-vector stuff. These are portable implementations of state of the art numerical algorithms. I'd suggest you try to 'vectorise' your numerical problems, as you'll then be able to use the BLAS/LAPACK libraries (via C/C++) to get the best numerical performance (and your code will make use of SMP where available, etc.). These algorithms are also very well tested. They are also free.
On some work I did recently, where I was trying to optimise the computation of a Moore-Penrose pseudoinverse (and had to code in C), I found that GCC on Windows produced faster code than VC++ (by about 10%, and I tried lots of compiler flag combinations). Although the problem was quite specific, the algorithm was fairly generic (for loops, standard C stuff), so I'd expect similar results in general.
People also swear by the intel compilers, but I didn't need the speed that badly to go and buy a new compiler.
My advice is to first make sure your numerical algorithms are correct, maintainable, documented etc. If your program isn't fast enough, profile it, and then optimise the slow bits. It's silly to prematurely optimise, or worry about getting the best performance from day one. So long as you don't shoot yourself in the foot (e.g. by deciding you can do better than all the numerical algorithms researchers), you shouldn;t worry about performance too much -- concentrate on getting the thing to work at all.
*Matlab has a reputation for being slow -- but this is because, for everything other than matrix-vector stuff, it runs an interpreter. So, if you're a C coder and you try to write a matrix-matrix product in Matlab's interpreted language, it will be slow. When you know to use the built-in functions instead of writing your own, Matlab will beat 99.999% of hand-rolled numerical C code easily.
C Rose
Sunday, April 11, 2004
The memory the application takes up may or may not be important. What definitely is important is that it meets the needs the customers perceive themselves as having and are willing to pay for. What is also important is that you go out and meet these customers and make sure you understand them, and they are willing to try out your product, and this can happen on the understanding that it is slow.
My opinion is that you are comfortable in a technical domain so you try to deal with that; and I'm not trying to be demeaning but that is one part in many, possibly one of the smallest parts, of running a business like this successfully. I only identify this because I've done just the same thing myself so I think I see your thinking; apologies if I have actually misread.
Konrad
Sunday, April 11, 2004
As for performance, the most important issue is what does
your market demand for performance? These need to
be answered, and it is rarely "as fast as possible" (although
it sometimes is). For example, if a program is interactive,
a couple seconds delay in crunching is probably OK. If it's
part of a networked infrastructure with "user" programs
interacting with it via API's, you may have more demanding
performance requirements.
Be sure to separate "required by the market" from
"aesthetic". Personally, I'm a huge aesthete in this sort
of thing, so I went to an area where the market and my
aesthetics complement each other :) But figuring out when
something is "good enough" is extremely important,
particularly since you always have limited resources and
other things (UI, standards compliance, reporting
capabilities, etc) may be the things which determine
success - not raw performance.
x
Sunday, April 11, 2004
Hi,
I have gone through the same experience and started pretty much with an equivalent skill set to what you have now.
It took me some five years and three releases to overcome most of the problems that you will probably have (and our product is number crunching at its best using anything from a few dozen to thousands of records) so be prepared for a steep and long learning curve. Having said that, shrinkwrap apps are not *that* different. You need attention to detail and you need to widen your knowledge to encompass UI design, usability and internationalisation. The first step is getting as many books as possible and read them.
We chose VB for the frontend and C++ DLLs for the time sensitive bits and the outcome wasn't bad at all. If I were to do it again I would probably go for a C++ only solution (either a portable one or MFC). On the other hand I learned a lot during the process and I am sure I would only be in v1 now had I started with C++ for everything.
What does help is figuring out what are the core features that your clients would want to see and concentrate there. If your app is sufficiently important your clients will probably not care if you don't support the latest bells and whistles. Very important: design for stability over speed for the first version(s). If it crashes all the time no one will see it fly over tons of records.
I think that the most important thing is not to despair too early, we are still very far from a large enough client base after all this time and I guess there's at least another five years until it starts in earnest for us.
Hope this helps.
JSD
JSD
Sunday, April 11, 2004
Whatever you do keep your day job, and farm out as much as possible.
the artist formerly known as prince
Sunday, April 11, 2004
RP, I'm impressed that you understand the difficulty, and that you correctly identify the need to do it in C++.
I have gone down the path you describe and it's much harder than it seems to the outsider. (You, surprisingly, seem to have a feel for this.)
A VB framework with C++ modules is an attractive option, and it's how I started. Eventually I upgraded to all C++, and this delivered powerful benefits in power and portability. However there is definitely a trade-off.
C# and its .Net cousins are fine for in-house corporate development, but not for commercial apps. Apart from the dependencies, there's also the matter of code discovery.
JM
Sunday, April 11, 2004
For me building the whole thing in C# is basically a big no-no because I'd have to learn a new language and for performance, it just won't do.
Maybe building a prototype in Visual Basic 6 is the answer, and then make the working thing in C++ using either Qt (I like it because I can theme it) or wxWindows. But when I build the prototype I have to make sure I don't use widgets that can be found in VB only, I guess.
RP
Monday, April 12, 2004
RP, dare I say it: Delphi (version 7 and below) has everything you want. And it is genuinely hated by some MS people, which gives it a cool factor. Even though Delphi's component architecture and syntax were directly copied by the .Net platform.
;-)
Bored Bystander
Monday, April 12, 2004
 Recent Topics
Fog Creek Home
|
