Hi all,

I have an idea for a computer program that I want someone to develop for me. Problem is, I have no programming knowledge at all. This program, I believe, is about as sophisticated as Microsoft Paint.

My question is this: If a talented programmer were to spend 40 hrs per week devoted entirely to developing Paint from scratch, how long would it take? Are we talking a month or a year?

Any help would be greatly appreciated. I realize this is probably not the appropriate place to post this, but thanks anyways.

You say that the program is as "sophisticated" as MS Paint. By what measure do you qualify the sophistication of Paint? If you're talking about a "Paint Clone," which I doubt, then there are many, many example programs available from which to start that could significantly shorten development time--if they meet the requirements. However, as noted, I doubt that you're looking for a mspaint clone.

If you currently do not have a set of written requirements, at least from your own perspective, then you will want to immediately double whatever estimate you *think* might be reasonable...if for no other reason than communicating requirements piecemeal and/or working through the requirements elucidation phase "during development."

MS Paint has undergone a very long time in use in millions and millions of computers with feedback being provided by a very large exposure to millions of people. It goes back to the first version of Windows, which was version 1.0, which was released in 1985. Since that time, it has undergone a number of revisions. We are approaching 35 years in the field in some version or another. Do not underestimate the complexity of the program and do not underestimate the value that having the kind of exposure that it has had with regard to the quality of its evolution.

For a given program, it may work fine for one user. Increase the sample size to a few hundred million using diverse sets of hardware, software and multitudes of other factors and see how well it works.

Unless you're experienced at estimating the complexity of an application, which I'm guessing that you lack this experience, my recommendation would be to seek complexity feedback from a variety of sources (which it sounds as if you are--at least indirectly).

In some ways, Paint can be thought of as a rudimentary application due to its rather simplistic user interface. However, there are many different technologies at work "under the hood" that are less visible.

While not specified in your post, I'm guessing that we can assume that you want the application to target the more recent Windows platforms and, because you're posting here, be written in C++. If this is the case, I'd probably recommend that you use Qt (or the services of a Qt developer) so whatever program you write will run on Windows/Mac/Linux with relative ease. Qt is a C++ based API and SDK used for building robust applications that provides a rich graphical user interface, networking, databases and much more while being very easily retargeted to a variety of common and some custom platforms.

Why invest your money in a new application development activity that can only reasonably run on one platform when you can do the same activities and target several different platforms?

If the application is solely for a special target audience of user categories, fine, but why not start with a robust API such as Qt, which would eventually give you the option to change your mind later, if so desired?

Even if you decide only to target Windows, you'll want to get a good handle on your requirements. Poorly stated requirements tend to add cost to the development effort. If you have at least a set of high-level requirements, you may want to plan a prototyping phase. That is, spend some money to get something that looks and feels like what you want it to do without all of the details plugged in and working as intended.

At that point, you can decide on the user interface and make changes until you're satisfied with the presentation of the content and that all of the user inputs and outputs are presented in an appropriate manner.

Estimate the time that it takes to make a prototype and then use the prototype as a baseline for how much it takes to "finish it."

Something on the order of 85% of all software projects are over budget in both time and cost. Either people aren't budgeting enough, or they are not properly scoping the complexity of their SW projects or both. Sometimes developers "drag butt," too, but no more or less than "other humans," I'd guess. Some complexity always arises in any non-trivial application development that sucks more time than would be expected...and for a wide range of reasons.

One of the biggest reasons why SW projects fail is because they were under scoped and therefore budgeted and because the "team" assembled were not sufficiently skilled to handle the tasks based on the schedule. Other reasons are because of disconnects in requirements and expectations.

It is common that laypersons deattribute the complexity of software development because of the seeming ease of which a visually representative prototype can be put together. "But you did all of this in a couple of weeks, why does the rest of it take several months?"

Part of the blame is due to SW developers who under-estimate their own abilities to deliver on promises made, but much of it is because it is easy to get 80% of anything right and fairly quickly completed, but much longer to get the final 20%, 15%, 10% and the hardest of all, 5% remaining completed.

Much of the reason for this is due to the growing complexity associated with the lack of good planning and iterative development, which includes constant refactoring, constant integration and constant testing/re-testing. Poorly planned projects tend to become poorly architected solutions and we all know that you can't buiild a good skyscraper using a shoddy foundation. However, when we suggest that the complexity isn't nearly as "demanding" as a skyscraper, rather, it is only a "two bedroom bungalow," we diminish the complexity of the task and often allow a bad foundation even if unintended. The problem is that without a suitable means of testing the system, without going back and redesigning and rearchitecting "problem areas" and without constantly building and integrating with those who must accept the project "as built" ...we're going to have something that probably doesn't do everything as desired.

Something else that can be helpful is to reduce the application to the smallest set of features that will do a specific intended task or small set of required tasks for one logical "block" of functionality representing some must-have feature(s). Have your chosen developer bid the task set and then see how closely the bid matches the results and whether or not the validation of those results matches the desired or expected results.

Track how well you believe your developer(s) is(are) performing on some arbitrary scale, such as assigning a 1 to 10 score for the following:

1: Meets general expectations
2: Completes tasking per estimations as provided by developer
3: Commicates Efficiently/Effectively
4: Produces verifiable results representing fulfillment of requirement(s)

...there are obviously many more areas for which one may want to rate the quality of services, but these tend to be at the top of importance.


If your developers are delivering well, keep them...otherwise, find those who will/can/do. Do not accept anything less and at least 90% across the board or you will likely be unhappy with the final product...unless of course, you find that 70% is acceptable by your own personal standards.

Also, ask yourself if you are part of the problem or part of the solution along the way. Is your developer(s) asking you for feedback on issues, such as button placement, wording or layout of text, etc..etc..? Are they responsive in asking questions that are detailed enough for you to answer? Are they just handing you "stuff" and expecting that it is good enough for you without seeking your feedback and/or complaining about how much work it is to change now because they've already gone ahead and "finished" some section without giving you a chance for a feedback loop?

Software development is a science and an art form. It requires interpersonnel skills and it requires being able to adapt "business rules" to user interfaces and backend data systems. All of this has to be able to scale to the intended use cases and interact without problems.

Ask yourself how you'd feel if, as a "regular Paint" user, it was suddenly to go away or behave entirely different or simply no longer run when you updated your computer? As a developer of a new software program, one has to consider such things, too.

It ain't easy...and if you receive answers that blatantly suggest otherwise, be skeptical.


MxB

WOW! Thanks Bob, that's a lot of great information. You're right, I have no idea how sophisticated Paint is. I wasn't thinking about what was going on behind the scenes in the "brain" of the computer. As far as C++ vs. Qt, I have no idea, that's why I have to hire a programmer. I should be more descriptive:

I have built a small-scale, functional version of this program in PowerPoint by simply covering each slide with buttons and linking the buttons to other slides. I guess this program would be a way of organizing, viewing/accessing and modifying pdf's for a specific industry.

Lets say I have about 10 thousand pdfs, about 5MB each in size. I can break those 10k down into about 5 heirerarchial categories. So at the top, I have the choice of 3 categories or folders, each of those folders is broken down into several sub folders, then the sub folders are broken down into sub-sub-folders and so on, until I get to the actual PDF I want to look at. All of these folders will have to be updated with new or modified pdf's daily. So organizing all of these pdfs is one component of the program.

Another component is modifying the pdf's via touchscreen monitor using existing technology. i will use a stylus to hand-write notes on the touchscreen, which will transfer onto the pdf's and be saved. Somehow, I have to link those handwritten notes to other documents saved as pdf's.

Of course, there would have to be an attractive user interface that is displayed and controled on the touch-screen. There are a few other functions that I don't want to go into detail on but I don't think they would be very difficult. Many of the users of this program would not be "computer savvy," so it cannot be too intimidating. My approach to this program is: a very limited number of features or functions (let's say 15 user-controlled features) but they must work flawlessly, everything controled via touch screen buttons and/or stylus, VERY attractive, modern looking yet simple display that is not intimidating for people that aren't as familiar with computers.

I know you guys can't give me a straight answer on how long it would take to build something like this because there are too many unknowns, but from a programmers prospective, does this sound especially difficult? If you were working full-time on this and I was very available to answer questions, how long do you think it would take? Any thoughts or opinions are greatly appreciated. Thanks again.

I think that you're trying to come up with an "architecture" for something based on what and how you think of computers, not was is "reasonable or feasible" from some of the many possibilities. Your heirarchical directory structure may be a good choice, but it may also be a poor choice.

What concerns me is that in one sentence you say that you basically want to annotate the PDFs in some fashion, whether the annotations "live" with the PDFs or as some kind of "linked" attributes associated with a given PDF "file name" or "directory structure location" or by some other association.

Then, you also say that you want to be able to update these with new PDFs as often as daily. Did we just destroy our associated annotations? How are we to track them? Are we to blindly assume that those annotations are now relevant for a given replacement PDF?

There is far from enough information to really begin to apply any kind of reasonable "scope" to the project. As I recommended, a prototyping phase that helps you explore your options is probably a reasonable choice. Obviously, a look at the PPT would be a minimum requirement to even get started with the project, but you apparently do not want to share that information. Let's see how fast that race horse runs with this anchor tied around his hind legs. How long will it take him to run a couple of miles? I dunno, how big is the anchor? How short/long is the chain? Is the horse very good at hopping?

I'd think that a minimum would be to sit (perhaps virtually) with a services provider for a few hours and go over your vision. During that process, the provider will likely be able to come up with at least an initial strategy that will be suitable for a prototype application to give some level of proof-of-concept to the project.

If the data storage method was to be a file system of PDFs (instead of perhaps using a PDF SDK to extract the content from the PDFs and store it in a database that would enable searching and annotating and "versioning" of that content), then one would start with a small subset of the whole and build a demo app that would do the basic set of desired functionality.

After that step, you would be in a position to evaluate whether or not the cost of the project was something you can afford...and that the provider would also be in a better position to make some kind of estimate of how much more work is needed to complete the vision.

You're basically asking for an estimate for an "artist" to chisel a David out of marble. The difference is that in your mind, you see David. What we see is some ideas about how to chisel--presumedly to accomplish the desired task of creating the David that you see without the prior experience of "just knowing" what a David looks like, such as is the case in the real sculpture.

Everyone knows what mspaint looks like, but that is most definitely nothing at all similar to what you've described already. Just the notion of "clicking" from one "linked" screen to another is completely different than how Paint functions.

With that in mind, we have to assess whether or not our "customer" has any real capability of explaining what is wanted without trying to tell us how to do it. If you MUST HAVE a directory structure because that is how you think of data on a computer, you've immediately placed boundaries on the implementation architecture. While this is not necessarily a bad thing, it isn't a description of how I think might be a better approach for you to try.

Start by describing the data sources or "feeds" that you apparently expect. Nobody gets potentially 10000s of PDFs a day without some kind of "feed." I don't know how someone can hand annotate even 100s per day, but that isn't a real problem, it is simply something to be considerate of when exploring the expectations of the system and understanding the user categories of the system.

Here is an example:

The SW must connect to a service (username, password, URL(s)) and download some number of updates or perhaps a package of some archived type containing a number of new PDFs.

...that is actually several "requirements" conveniently rolled into a distinct group that would represent "fetch data."

You probably don't want to say "Put the PDFs into various folders" as a requirement, rather, you will probably want to decide what must be done in terms of working on the content contained in the PDFs. How is the data stored in the portable document format to be used by the system and/or the user? Don't think about how to accomplish it as much as how it will be used by the various kinds of users that would use the system.

Are they later supposed to know that the program manages these numbers of PDFs and that they are stored in specific locations? ...or is that a better job for the computer and we write software to free the users from having to think about how the PDFs are "managed" and let them focus on the content?

We've assumed that the users must be able to read the content and we've heard a requirement to annotate it in some fashion and that the annotations must be stored, but we've also heard that we may potentially overwrite an "old" PDF with an updated PDF. Better would be to describe your expectations of how the user would use the data both from a content perspective and from the annotations perspective and how, when, if that would need to be later recalled, shared or otherwise used in some fashion. I mean, we can obviously assume that somehow it must be done, but for what purposes? Are we perserving legal or medical documents? There are all sorts of industry requirements and even laws associated with how some kinds of documents are maintained. Are we marking up recipes and practising them in kitchens around the world?

There needs to be some kind of sharing of information specific to the project that will often dictate some requirements that you've probably never considered.

Take some time to describe who the users are for your system. If "they" are a body of just one person or if they are an entire group of professionals in a certain field, it helps to know as much as possible about the users.

Something else to be considerate of is data that you store is only as useful as your ability to retrieve it and use it when you want it. Therefore, you probably need a better organization method for the multitudes of PDFs than a hierarchy of directories with multiple subdirectories. You probably need some kind of indexing and search capabilities. I think that most users despise having to wait for searches to complete...and then having to manually sort through the results looking for that nugget that represents what they actually wanted. What user experiences do you envision for your system?

Those are the kinds of things that you want to expand on. Try to place what you think are reasonable expectations of system performance and capabilities. Try:

System must locate searched documents by title matching of two or more words within 30 seconds when the number of stored documents is at least 10,000 but less than 100,000.

These are meaningful requirements, even if you're unsure of the performance requirements. They give something for which, if met, is fulfilled by the system--at least for the "current version." They also make some kinds of implementations unreasonable choices by eliminating those that could easily exceed the performance requirement. It also sets up some test criteria to be met after the move from "prototype" to "real app" begins.

Start by writing a vision statement for your system. What is your system and what does it do in three (reasonably lenghted) sentences, or less. If you can describe, at a high level, your system in a short paragraph, then someone else can understand it, too.

Lastly, consider that you've been thinking of your system for some period of time, probably more than a couple of hours--perhaps many days, weeks, months or possibly years. Even if it is just a few hours, that is much longer than anyone else has been thinking about it. I don't know how fast I think, but it is A LOT FASTER than I type. Perhaps a million words a minute? Certainly it must depend on the subject matter and a billion other things including interruptions, stray thoughts and whatever I just happened to google that may have led me to think about sword fighting in ancient Egypt while climbing the yet uncompleted Gaza pyramids. However, even all of that may have happened in less than 10 seconds and you've had at least several hours of time producing your PPT and thinking about your system before ever coming here with it.

Distill your thoughts into one paragraph. Make that paragraph sum things up. It is a lot harder than it sounds, but if you can do it, maybe your project has a chance. Without a clear vision statement, I would suggest that the chances of success for a non-programmer are practically nil.

None of this is meant to be rude or inconsiderate. However, think for a moment how rude and inconsiderate it is to take your money as long as you're willing to withstand it all the while not producing what it is that you really want but just giving you something that kind of looks like something that you can live with, but doesn't really complete the tasks that need to be accomplished in order for you to realize the benefit that the system must provide. While few programmers probably present these notes in this manner, sometimes they just happen because nobody ever talked about it becoming a reality without some decent planning.

If you truly have enough bandwidth to be fully available to your development staff during the course of the project AND if you are truly capable of making the kinds of decisions about the system that only you can (when presented with them by your developers), then you are at least miles ahead of those who cannot...and, perhaps even lightyears ahead.

Again, communication is the key to success in just about every relationship, whether personal or professional. If you mix the two, you're either a better man than me or you're taking a bunch of chances that I'd never attempt.

Perhaps the greatest asset you can bring to bear on any project is plain old common sense. It won't buy you any cups of coffee, but it will probably keep you from giving away too many free lunches. Trust in your instincts, but question everything. Those who are professionals will expect it and build up their side of the relationship so that they anticipate your needs and answer your questions before you ask them. If you don't get that from your development team, find a new team.


MxB