What tools do you use to design?
-
I kinda get a feeling that most here are some sort of professionals ;p I mean at least make "some kind of money out of software to which they have contributed". I think I am not wrong if I say most here also do "hobby" projects. At work, most are "supposed" to use certain tools and procedures. And by themselves, they either are "spoilt" by practice and continue the same that they employ at work or may use their tried-n-tested methodology. I am interested in the kinds of tools and procedures that you guys make use of during the design stages, both at work and by yourselves. Do you (prefer to) use those fancy block/cloud diagram tools, flow charting tools and the like? Personally, I prefer paper and pencil. I draw and jot down stuff using those. Oh, an eraser is handy as well ;) If I need a soft copy of that, I use notepad where I use bullets and indentations to organize the ideas and layout. And somehow, I am lucky to be able to use this method at work too. (I mostly develop useful, reusable, non trivial components, along with an assistant, although at times I am also involved in using them in some of our products beyond the "demo" level). And I must not fail to emphasize that I dream a lot. I mean, I imagine a lot about the component, including the code that's going to come! So, most part of it is designed in the head but I sure do comment about those both in code and design document (although I am lazy to reproduce every thought into words and diagrams but I think thats OK as of now as I am the one who's in charge of what I do and also I can brief them to the bosses, unambiguously, when needed).
...byte till it megahertz...
Hi Vinay, here is my basic approach: It usually starts with - paper and pencil - whiteboard - show/talk/brainstorm with available/local experts (ideally focus on understanding the "ideas/problems") - take a walk, coffee break, music, shower.. whatever helps to be creative and get a good overview (no rules) then continues with - initial sketches in Editor, OpenOffice, Visio (what's available)... see next step why: - show/talk/brainstorm with experts and stakeholders, design reviews with those who will later use it - apply some of your processes to get something written down (ideally focus on good "alternatives") - narrowing down... prepare to switch your brain from creative to productive mode (really hard!) and ends with: - finalise documentation (ideally focus on "solutions" and not on throw-away reports) - apply processes and "get it done" to the quality needed, e.g. documentation in a special form, reviewed, approved - present and explain to people using it (unpack your show master qualities) - set up a follow-up meeting for feedback/improvements/retrospective (also see agile development) Hope this helps :) /M PS: With processes I mean best practices or development processes in your work area.
Chat in Europe :java: Now with 24% more Twitter
modified on Sunday, August 22, 2010 6:34 AM
-
I kinda get a feeling that most here are some sort of professionals ;p I mean at least make "some kind of money out of software to which they have contributed". I think I am not wrong if I say most here also do "hobby" projects. At work, most are "supposed" to use certain tools and procedures. And by themselves, they either are "spoilt" by practice and continue the same that they employ at work or may use their tried-n-tested methodology. I am interested in the kinds of tools and procedures that you guys make use of during the design stages, both at work and by yourselves. Do you (prefer to) use those fancy block/cloud diagram tools, flow charting tools and the like? Personally, I prefer paper and pencil. I draw and jot down stuff using those. Oh, an eraser is handy as well ;) If I need a soft copy of that, I use notepad where I use bullets and indentations to organize the ideas and layout. And somehow, I am lucky to be able to use this method at work too. (I mostly develop useful, reusable, non trivial components, along with an assistant, although at times I am also involved in using them in some of our products beyond the "demo" level). And I must not fail to emphasize that I dream a lot. I mean, I imagine a lot about the component, including the code that's going to come! So, most part of it is designed in the head but I sure do comment about those both in code and design document (although I am lazy to reproduce every thought into words and diagrams but I think thats OK as of now as I am the one who's in charge of what I do and also I can brief them to the bosses, unambiguously, when needed).
...byte till it megahertz...
Start with paper and pencil - best design tools there are.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Start with paper and pencil - best design tools there are.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Hi Vinay, here is my basic approach: It usually starts with - paper and pencil - whiteboard - show/talk/brainstorm with available/local experts (ideally focus on understanding the "ideas/problems") - take a walk, coffee break, music, shower.. whatever helps to be creative and get a good overview (no rules) then continues with - initial sketches in Editor, OpenOffice, Visio (what's available)... see next step why: - show/talk/brainstorm with experts and stakeholders, design reviews with those who will later use it - apply some of your processes to get something written down (ideally focus on good "alternatives") - narrowing down... prepare to switch your brain from creative to productive mode (really hard!) and ends with: - finalise documentation (ideally focus on "solutions" and not on throw-away reports) - apply processes and "get it done" to the quality needed, e.g. documentation in a special form, reviewed, approved - present and explain to people using it (unpack your show master qualities) - set up a follow-up meeting for feedback/improvements/retrospective (also see agile development) Hope this helps :) /M PS: With processes I mean best practices or development processes in your work area.
Chat in Europe :java: Now with 24% more Twitter
modified on Sunday, August 22, 2010 6:34 AM
+5 for replying. :) Thats interesting. LONG but interesting. In the second stage where you have to interact with the stakeholders, how "neat and proper" will you let those sketches be? (I am not talking about the correctness)
...byte till it megahertz...
-
+5 for replying. :) Thats interesting. LONG but interesting. In the second stage where you have to interact with the stakeholders, how "neat and proper" will you let those sketches be? (I am not talking about the correctness)
...byte till it megahertz...
Thanks. I usually involve them from the very beginning, if possible get everyone's ideas and wishes... then the sketches are not even existing. :) Otherwise anything that can be printed out on paper or projected onto a wall works for me, so not very "neat and proper" but sufficient to get the idea across. Generally, I wouldn't spend more time than necessary on things under constant change.
Chat in Europe :java: Now with 24% more Twitter
modified on Tuesday, August 24, 2010 8:47 AM
-
Thanks. I usually involve them from the very beginning, if possible get everyone's ideas and wishes... then the sketches are not even existing. :) Otherwise anything that can be printed out on paper or projected onto a wall works for me, so not very "neat and proper" but sufficient to get the idea across. Generally, I wouldn't spend more time than necessary on things under constant change.
Chat in Europe :java: Now with 24% more Twitter
modified on Tuesday, August 24, 2010 8:47 AM
Yup, we after all aren't using Photoshop are we :D ('cause thats how I have seen many people construct their diagrams, even in initial stages like you mentioned, even for presentation amongst ourselves, and not to mention the colored excel sheet cells :wtf: Boss points I guess X| )
...byte till it megahertz...
-
Yup, we after all aren't using Photoshop are we :D ('cause thats how I have seen many people construct their diagrams, even in initial stages like you mentioned, even for presentation amongst ourselves, and not to mention the colored excel sheet cells :wtf: Boss points I guess X| )
...byte till it megahertz...
I know those people, they never deliver and spend much time on writing reports. Those with colors are the worst. :D What's important for me is the final product! It has to be of good quality, look good, be well documented... and ready in time. I would try to pull that off to get boss points and a happy customer. :)
Chat in Europe :java: Now with 24% more Twitter
modified on Tuesday, August 24, 2010 9:25 AM
-
I know those people, they never deliver and spend much time on writing reports. Those with colors are the worst. :D What's important for me is the final product! It has to be of good quality, look good, be well documented... and ready in time. I would try to pull that off to get boss points and a happy customer. :)
Chat in Europe :java: Now with 24% more Twitter
modified on Tuesday, August 24, 2010 9:25 AM
-
Start with paper and pencil - best design tools there are.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I kinda get a feeling that most here are some sort of professionals ;p I mean at least make "some kind of money out of software to which they have contributed". I think I am not wrong if I say most here also do "hobby" projects. At work, most are "supposed" to use certain tools and procedures. And by themselves, they either are "spoilt" by practice and continue the same that they employ at work or may use their tried-n-tested methodology. I am interested in the kinds of tools and procedures that you guys make use of during the design stages, both at work and by yourselves. Do you (prefer to) use those fancy block/cloud diagram tools, flow charting tools and the like? Personally, I prefer paper and pencil. I draw and jot down stuff using those. Oh, an eraser is handy as well ;) If I need a soft copy of that, I use notepad where I use bullets and indentations to organize the ideas and layout. And somehow, I am lucky to be able to use this method at work too. (I mostly develop useful, reusable, non trivial components, along with an assistant, although at times I am also involved in using them in some of our products beyond the "demo" level). And I must not fail to emphasize that I dream a lot. I mean, I imagine a lot about the component, including the code that's going to come! So, most part of it is designed in the head but I sure do comment about those both in code and design document (although I am lazy to reproduce every thought into words and diagrams but I think thats OK as of now as I am the one who's in charge of what I do and also I can brief them to the bosses, unambiguously, when needed).
...byte till it megahertz...
I end up using MS Paint for design actually. Don't laugh, I got used to it. Visio or other UML tools can end up eating a lot of time, so I first create quick & dirty designs with paint (copying and pasting makes it quite speedy) and if necessary translate that into fancy design with a real UML tool later.
-
I end up using MS Paint for design actually. Don't laugh, I got used to it. Visio or other UML tools can end up eating a lot of time, so I first create quick & dirty designs with paint (copying and pasting makes it quite speedy) and if necessary translate that into fancy design with a real UML tool later.
No I didn't laugh. When needing rough sketches in a soft copy, I use MS Excel and MS Paint. The cell formatting in excel saves me the trouble of aligning text, filling color etc in paint. Paint is just to cut the big screen capture, organize the boxes and other things like lines etc. I have a couple of paints running. People may find this unproductive but they got to use it to see it.
...byte till it megahertz... my donation to web rubbish