What tools do you use for designing software?
-
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?
After the paper, pencil & brains phase I'd suggest e.g. Visio: easy to acquire, pro look&feel, and also has some reasonable optional code-generation possibilities. In my experience, the more enterprisy and thus expensive the tool, the more useless they tend to be in daily business life (if anti-spamming is allowed here, this would include e.g. Select and any Rational product). Another option is the Class Designer in Studio, but is 1-on-1 with your type artifacts; advantageous, but already detailed and thus not always adequate as a design tool. Would be nice to have Studio mature further with integration of Visio layering and e.g. Borland Caliber RM (reqs mgmnt) as a standard integrated plug-in; together with MSF, work items and class designer this would bring almost the full cycle into a single tool.
-
peterchen wrote:
But they'd have to get laid for that
If you are redesigning your own DNA, hey, why not custom design your own mate first?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Deal! Just think of the possibilities for case modding...
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
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?
How long is that piece of string ? Most of the work is done by the human brain, at varying levels of consciousness. I tend to come up with my best, most parsimonious designs whilst driving and getting slightly hypnotised by the thrum and vibration of it. Then there's a whole suite of tools to realise the ideas on paper & 'in silico'. Then there's testing. And user feedback, which occasionally is great. Your development IDE is more important than most software aids, but less important than communicating properly with the team and end users. So, if you want a project to go smoothly, above all else make sure you don't have extra communication barriers like non-English-speaking people in the team. On the other hand, I actually think it's worth having one pillock who everyone can disrespect, and who therefore allies the rest. So maybe have a Scottish, disapproving, hatred-meister to fill that role safely. Beware arguments about differing platforms and technologies - these must be resolved quickly without descent into slanging matches. N
'All there really is, is: virute and vice' ...Black Crowes
-
Okay, if all you "Real Men" are done designing your "perfect" mate to have your designer children do your designing for you, there are lots of us "Real" women who do design… First, I ask my users what they want/need, then yes I use pencil (or pen) and paper sometimes to get an idea of what they want. I also have THEM use the pencil and paper to show me an idea of what type of interface they want. I design web pages BTW, so once I have an idea what the user wants/needs, I use Visual Studio to easily design something in HTML to have a "Demo" to show them. There are lots of tools, all kidding aside, plain old pencil/pen/paper to get the initial idea still works best - just put the burden of what the user wants back on them - make THEM give you the initial design in pen or pencil... Just my .02 cents...
Coleen NV DMV ISS 3
Coleenh wrote:
There are lots of tools, all kidding aside, plain old pencil/pen/paper to get the initial idea still works best - just put the burden of what the user wants back on them - make THEM give you the initial design in pen or pencil...
Amen and Amen
Shohom67
-
Coleenh wrote:
There are lots of tools, all kidding aside, plain old pencil/pen/paper to get the initial idea still works best - just put the burden of what the user wants back on them - make THEM give you the initial design in pen or pencil...
Amen and Amen
Shohom67
Doesn't anyone else think that it is a little strange and a bit of a paradoxical that we develop software and yet we rely on pencil and paper? I've ever so wanted to electronically store the ideas and creativity of the initial design but I have never found the right tool. Does anyone have a serious answer besides pencil and paper?
-
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?
Flip charts and pens for the use case diagrams, plus blue tack to stick them on the walls. Whiteboards and different pens (don't get them mixed up!) for everything, plus a digital camera so we can store the images. In fact the only spaces in my office that do not have whiteboards on them are the walls behind desks where we can't reach, and the windows and doors. Although it would not be the first time we have drawn on the windows 'cos the board wasn't big enough. ;P MS Visio for data flow diagrams and entity relationship diagrams, but only because it is on my machine and I don't have anything better, but it is still easier to modify than a whiteboard without having to draw everything again. VS '05 for interface design, although I have a beta of MS Expression that looks cool for AJAX stuff. Probably not the software answer you were looking for, but I don't have to train anyone (mostly) on how to use a pen and a board and everyone has the software to view a photo.
-
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?
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
-
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