What tools do you use for designing software?
-
It sounds like you mean "How do you design code", not "How do you design an interface". If the problem is complicated enough that I can't just sit down and write the code, I use pseudocode, preferably on a whiteboard. I use very high level "statements", like do while alive open files get devices play song conquer universe end do get old and die That way, I can deal at a high level with the overall flow of control, then go back and pseudocode the individual steps. But I usually find that the devil is in the details. There are unexpected dependencies, and I have to start over. Of course, this assumes that you are working in a procedural environment. I know people who use an "Object-Oriented" paradigm. They begin by designing the classes they are going to use to solve the problem. I don't know if there is a second step to this methodology. I have never seen anyone finish step 1. JBB
Your right about the "how do you design code" comment. Even closer would be the question: How do you organize your task list after the software is designed and the interface is laid out? Do you just make a task list in word, or do you use excel, or maybe a different piece of software. I have a start at the design of the software I will be building and am ready to start my "technical design" and am looking for a good way to organize the different pieces so that I can start estimating the time each piece will take.
-
Your right about the "how do you design code" comment. Even closer would be the question: How do you organize your task list after the software is designed and the interface is laid out? Do you just make a task list in word, or do you use excel, or maybe a different piece of software. I have a start at the design of the software I will be building and am ready to start my "technical design" and am looking for a good way to organize the different pieces so that I can start estimating the time each piece will take.
Estimating is a whole 'nother matter. If you simply want a list of pieces of code that will need to be written, the pseudocode will provide that, at whatever level of detail you take it to. But there is also the question of design of files or databases, and then there is the question of "testing". The usual development paradigm looks like this; design => code => test => deploy The problem with this is that it assumes the function of testing is to verify satisfactory performance. That shouldn't take long, should it? I could write a book, and maybe I should. But let's cut to the chase. The first question to ask about any document is, "Who is the intended audience?" This applies in spades to a coding time estimate. If you are a contractor, and the reader is a prospective employer, you want the estimate as short as is remotely plausible, so you will get the contract. They won't fire you when it's half done. This may sound cynical, but I assure you it is the standard industry practice. How do you think they make all that money? If you are an employee, and your boss wants an estimate, make him help you develop it. Then he is on the same hook you are. Otherwise, when anything takes longer than YOU estimated, it is YOUR fault. So, yes, your question is a political one, not a technical one. If you build five houses a year, all exactly alike, you have a pretty good idea how long it takes to build one. But no one ever builds the same program twice, and no one has any idea how long it will take to build the next one. JBB
-
When you already have your project figured out and you are at the stage where you need to start planning exactly how you are going to develop the software what tools do you find the most useful?
a whiteboard that prints