101 of Development Programming

foozball3000

foozball3000

Executive Member
Joined
Oct 28, 2008
Messages
5,928
Reaction score
1,738
Location
Kyalami
I didn't begin my programming career in a University or some software development shop.. mine started with a Quick MCSD Course, and some play time on a C# Editor.
Then my first (current) programming job is in data analytics. We do develop a lot of software, but they're usually just quick and disposable tools.

So, as a result, I never learned the 101's of Development Programming.

Apparently, I first need to compile a requirements sheet, then design the project (which includes research and resource gathering), and then I can start coding. Our typical, storming into the project with keyboards blazing, won't cut it this time as this project is HUGE.

So, how do I write a requirements sheet? It's name says it all, but somehow I get the feeling that it might not be that easy.
 
Normally the fist thing is to get a signed off requirements document from business. Then you have system analys who creates more technical specs / use cases (There are lots of names for these docs depending on where you work).

From there the Architect will normally draw up some form of a architecture document then the coders uses that and the use cases to start coding.

There is a lot of different approches to this process though, if want to do some reading look at things like:

Waterfall Approach
Extreme Programming
RUP - Rational Unified Process etc. etc.
 
Veroland said:
Normally the fist thing is to get a signed off requirements document from business. Then you have system analys who creates more technical specs / use cases (There are lots of names for these docs depending on where you work).

From there the Architect will normally draw up some form of a architecture document then the coders uses that and the use cases to start coding.

There is a lot of different approches to this process though, if want to do some reading look at things like:

Waterfall Approach
Extreme Programming
RUP - Rational Unified Process etc. etc.
Click to expand...

Waterfall Approach : http://en.wikipedia.org/wiki/Waterfall_model
Extreme Programming : http://www.extremeprogramming.org/map/project.html
Looks like fun :rolleyes:
Thanks for the pointers :)

I should probably mention that this is a one man project?
I need to design everything up until the actual coding...
 
+1

Software requirements specification is indispensible to minimize scope creep; the bane of any programmer's life.

Make extensive use of use-cases; the more the better. Other forms of UML are encouraged.

To allow your software to adapt to changes, agile methodologies should be employed.

Extreme programming kind of flies in the face of the rigid requirements spec; basically building a throwaway program to see what works and what doesn't etc.

At the end of the day, the procedure you follow is heavily based on the particular project in question.

If you have time, you should read a book on software engineering.
 
It seems that I've found some good material on it... I'll start with that and see how far I get. :)
Thanks guys.

P.S. @sn3rd, any specific software engineering books that you'd recommend?
 
I'm studying this right now. Go to Kalahari and look for the prescribed book for UNISA's INF206 module. Good book...
 
Hehe, yea I remember when you're so excited about a project that you just start and don't think it through.

We usually do our sys requirements after business gave us what they want and we interrogate them to hell (business can be vague with what they want, the pudding is in the detail so we usually have a 2/3 day thing going through everything asking questions from our side in terms of functionality and impact on the overall project)

Then we do db design and hash out any other potential problems or questions that may come up and from there on we break things down into modules. Check which one compliments which, which needs to go in first (for example, user authentication goes in first) etc etc etc and grow from there.

By the time you're finished with all the modules you're done with the project. Key is to focus on the small "cogs" that make up everything and make sure the wheel turn at the end of the day. So daily testing on modules written by the dev team is essential. Especially when 1 can impact the other.

I hate documentation :D
 
AcidRaZor said:
Then we do db design and hash out any other potential problems or questions that may come up and from there on we break things down into modules. Check which one compliments which, which needs to go in first (for example, user authentication goes in first) etc etc etc and grow from there.
Click to expand...

I hate the fact that they never can understand that the "plumbing" takes time and needs to be there before you can start to show real or quick progress.

AcidRaZor said:
I hate documentation :D
Click to expand...

With you on that one
 
The documentation that I DO find very useful though, is proper commenting in C# code. It just makes using someone else's classes, methods and properties so much more intuitive, as you know exactly what the person coded it for. You don't have to use method void GetX(int y) or property bool TrueOrNot and pray to God that it doesn't format the hard-drive.
 
Remember, There is a difference between comments in your code and self documenting code. With self documenting code I mean using variable, menthod and class etc. names that tell you what they do without the need for extra comments
 
FarligOpptreden said:
The documentation that I DO find very useful though, is proper commenting in C# code. It just makes using someone else's classes, methods and properties so much more intuitive, as you know exactly what the person coded it for. You don't have to use method void GetX(int y) or property bool TrueOrNot and pray to God that it doesn't format the hard-drive.
Click to expand...

Sounds like there is a rather good story behind that... :rolleyes:
I too find commenting very handy, as our company seems to randomly bump you on different projects, so a month later when you have to revisit your code, it helps to know what you were thinking when you originally wrote it.
 
Veroland said:
Remember, There is a difference between comments in your code and self documenting code. With self documenting code I mean using variable, menthod and class etc. names that tell you what they do without the need for extra comments
Click to expand...

Yes, I know. I was just adding to the "documentation" topic by stating the type of documentation I DO like... :p Chill Vero...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X