How do you get your ideas to code?

Hi guys,

As you may know im begining to get serious about programming. One of the things i find i have a wee problem with is... How do you get your idea to code. Consider the following:

I have an idea for say a code bank, how would you go about all the details say what goes in to the UI or what you want in the database. I tend to have a very (ok very very) brief mind map and then run in head first (and fail!) because i get stuck on the details.

So do you just go and code or do you write up documentation first?

some people use UML, some just think a bunch of stuff up before coding on how they're going to approach something, some people just get right into coding it, etc etc. it's all preference.

Ive never used uml, i do think i need to change im getting very little done!

whatdya making? :P

Well ive an awful habit of forgeting things like bank details etc, i have bits of paper everywhere, so sort of like a bank for these things. I also wanted to demonstrate how well i know: Classes, Data access, xml (im planning on having a mobile version that i can add too and send back to the main program) and basicly seeing a project from start to finish.

The problem is ive started it about six times now because i keep adding or removing features, basicly id like to know how other people "blueprint"!

yea try uml

Il have a look tomorrow so!

I usually just start coding. If I'm lucky I will finish the project and it will work relatively good, then I'll slowly add features etc, if not, then it doesn't really matter cause usually I've learned something new.

If I am serious about a working end product then I will sit down and map it out on a a few thousand forests of paper. I use UML to map out the structure but don't really bother with use cases or sequence diagrams.

To get the end product I need to be able to see each part working in my head - visualise it I guess and because OO is great, when you visualise the parts you can then visualise how to put them together.

Tools like Viso IMO are only for showing other people. The best ideas come from a pen and paper.

Quote:

---

Originally Posted by CodedFire

Well ive an awful habit of forgeting things like bank details etc, i have bits of paper everywhere, so sort of like a bank for these things. I also wanted to demonstrate how well i know: Classes, Data access, xml (im planning on having a mobile version that i can add too and send back to the main program) and basicly seeing a project from start to finish.

The problem is ive started it about six times now because i keep adding or removing features, basicly id like to know how other people "blueprint"!

---

Go and see a doctor. Your forgetfulness is clearly encroaching on your coding. :D

whats UML?

Unified Modeling Language

The client gives you their problem to solve and you have to code a software solution for it. :D

Usually if its a decent size program I will flow chart it but most of the time I start designing the GUI along with it to help me organize and visualize.

I look at other applications freeware or what ever and see if i can produce something like it, not exactly but something with the same outcome.

But more recently i have been getting more involved at RentACoder finally landing my first job and 3 more in the works :D

Quote:

---

Originally Posted by CodedFire

How do you get your idea to code.

---

It comes to me in my InBox. :D

Quote:

---

Originally Posted by CodedFire

So do you just go and code or do you write up documentation first?

---

I don't write documentation....we have a technical writing staff for that. :thumb:

@ Hack, could i borrow your staff :)

Ive looked at uml, and to be honest their is alot of learning in it that i dont have time for right now. I do like wossnames and rob's idea's. Come up with the idea and write up an overall structure based on needs of the app via pen and paper. Thanks to all who responded!

In the mid-1960s, mathematicians proved that any program, no matter how complicated can be constructed using one or more of the three structures of structured programming.
Sequence, Selection, or loop, with these three structures alone you can diagram any task, from doubling a number to performing brain surgery.
You can diagram each structure with a specific configuration of flowchart symbols.
Inconjunction with flow charts, even the most difficult concepts can be conveyed and more importantly understood.

"Documentation? We don' need no stinkin' documentation. If it was hard to write, it should be hard to use."

-tg

srsly tho - I usually start by outlining the steps and processes, then go into class designs, and then start working with the UI, then I go back and refactor each part over and over and over - when building the UI, there's always someting forgotten in the class, which usually involves in a change to the processing as well.... once I've got the 90% solution, I start coding.... making changes to everything along the way.

-tg

I used to jot down notes, generally while lying on the floor. Now I have realized that I can type faster than I can write, and it's even legible. I still do some sketching for visualizations and trig issues, but most of my notes are now in Word. Much easier to organize and edit that way, but you have to be a fair typist.

So it seems that coding is always the LAST proccess

NEXT to LAST.... testing is always last.

-tg

testing??? agile, put it all down on lil sticky notes then start coding, when your out of sticky notes send it to QA...

Quote:

---

Originally Posted by CodedFire

@ Hack, could i borrow your staff :)

Ive looked at uml, and to be honest their is alot of learning in it that i dont have time for right now. I do like wossnames and rob's idea's. Come up with the idea and write up an overall structure based on needs of the app via pen and paper. Thanks to all who responded!

---

Basic UML is very easy to learn. If you do not understand the terms then I would be inclined to say - learn more about object orientated design first.

I wouldnt say its hard to learn (i spent more time this morning over it). Maybe its more that i just dont like it. I dunno why since i learned to pseudo code and love that. I suppose its personal tastes when it comes to UML really.

It provdes a visual respresentation. A picture tells a 1000 words. ;)

Quote:

---

Originally Posted by visualAd

It provdes a visual respresentation. A picture tells a 1000 words. ;)

---

Not really a picture, it's just a couple of rectangles and a thousand words

Quote:

---

Originally Posted by ComputerJy

Not really a picture, it's just a couple of rectangles and a thousand words

---

Thats exactly why im not to fond of it. I understand to go pro it may be in my intrest to learn it though. Anyhow what ive decided to do is:

1: Jot down the overall requirements, ie what it does, what data needs to be presented and in what style.

2: Mock up the gui and database to said requirements.

3: Use Psudeo code to map what classes, methods and functions are reqiured.

4: Edit the gui based on how best the classes, methods and functions tie together.

5: Lather, rinse, repeat :)

Thanks for all your suggestions guys, at wossname and robdog, rep+ as im using a mixture of your ideas!

Actually these days the "Extreme Programming" approach is a hit. look it up. it's good for people who hate UML

Cool il do that in a bit and let ya know what i think

Looked up extreme programing, good for teams but other than that i would have no need for it!

Class design is my main focus, followed by how classes interact, and code flow.

GUI design is the least of my worries.

chem

Quote:

---

Originally Posted by CodedFire

Looked up extreme programing, good for teams but other than that i would have no need for it!

---

If you are looking for design time stuff. Flowcharts are the easiest out there. they are just like pseudo code except they are drawn, they explain how things are done and are useful when reusing.

For class diagrams I always use the "Reverse Engineering" button in VS provided by MS Visio. code makes more sense to me than UML

My boss tells me what to code. :D

I don't code anything myself anymore.

I'm a network engineer for my job.. when I get home.. or, even randomly like right now, I help others with their programming. I don't really have time to write my own full-on applications.

chem

If I'm on a home project, it'll be a sheet of scrappy A4 with tons of diagrams and notes which only I can make sense of and put in order, but which probably looks like a 4 year old's drawing.

Out in the field it is generally required to write professional functional specs which detail the project in clarity. In large companies, you would then produce development UML and data(base) definition guides for the programming team, and also from the start, testing documentation. Whether it's a small home project or a customer project built by the MS team but in essence, you're going to be performing the same steps:

• Look at what's needed and write some form of list
• Look at what's on the list which is nice to have and what's essential (try to concentrate on the essential 1st to get the base of your app to add to later)
• Look at common functionality and start thinking in terms of objects "I have a customer ordering system, therefore I need to have customers, products which they can order, and orders".
• Process these into some form of list or diagrams for both a database schema design (if required by the app), and class design
• Use these and the original requirements list to think about the forms you'll need to provide
• Finally think of a menu structure and UI

I had an old colleague who used to put psuedocode into each class for what the class should do, and what the methods contained in it would do - the whole class apart from method descriptions would be comments on the steps to approach what the methods did which I thought was a great, professional approach and one which I really should take up at some point.

It's far more fun writing the code & designing the UI's, but without any form of soe of the above (certainly points 1 and 2), you'll be forever changing and adding to the app and it will both be (i) more of a hashed piece of shoddy work in the polite sense, and (ii) will take far longer to write when you include these chunks of re-writes and alterations, as I've done myself on many an occasion :blush: :bigyello: :lol:

Yep I'd go along with coding is always the last.

Quote:

---

Originally Posted by techgnome

NEXT to LAST.... testing is always last.

-tg

---

I've just started a role in testing at Nokia Seimens Networks - not having done hardly any of it in all my other programming roles/teams so thought it'd be cool to know this side more.

There's a load of different testing methods but the earlier the testing starts, the better - from testing bodys in the UK, there should be a testing person/team writing the documentation for the tests at the same time as the screen designs, functional specs and requirements docs are being put together (& I read about a practice of developers writing test harness apps before writing the body of the methods they were testing), so I'd have to disagree with that statement ;)