How do you visualise your work? Software Engineering?

krazyklown

Bit of an airy-fairy question but i have two or three projects in my head but i cant seem to get started! like all hackers i just want to get down and start coding but i know i should be planning first but how do you kickstart the process? do you visualise the end result and try and work backwards (using pen & paper doodles?) Do you work from the GUI first and then work out the implementation or the other way round. What about test-driven development, i was looking at a few tutorials on that!

Is there an industry standard approach, i learned about development cycles (incremental, waterfall etc) in college, are they used much?
Or is it a case of just start coding and keep refining it until you are happy?
Any links or templates that would help guide me would be appreciated!

fasty

I write a spec. Something basic will do, some bullet points of what you want it to do, a few drawings, a series of steps to take.

From there, I code.

If it's a business type application or something for the web, I'll typically model the data, create some dummy classes and knock together a quick and dirty UI then take it from there.

For a game or something, I'll make a list of requirements for what I need to make the game happen. We're talking libraries needed, stuff I might need to code myself etc.

After that, everything else flows great for me, rewrites and mistakes are par for the course as is writing ****e code. Don't be afraid of it, you'll never one shot any project no matter how good you are.

TDD and other methodologies have their place. I find that until you've got a prototype up and running, TDD can be counterproductive. It's hard to write failing tests and then passing implementations with nothing there to begin with!

Take design patterns with a pinch of salt. They're useful but by no means a silver bullet. Sometimes, you're as well off letting things evolve.

And last but not least, release what you make. Smarter people than me have always said that if you're not embarrassed by version one, you didn't release early enough! Get other people involved, get their feedback!

jmcc

Figure out what you want to do.
Figure out what you have to do to do it.
Do it.
Figure out what you don't need to make it work well.

(The last part is the hardest.)

You have to be able to define the problem to be solved. If you cannot then you will not know when you have solved it and will probably hit upon the right solution by accident. This is fine for college where the lecturer might not even be a real programmer but in the real world, you've got to get it right all the time.

Regards...jmcc

Sparks

It depends on the segment of the industry that you're working in. How I worked in startups and SMEs bears fairly little resemblance to how I work in IBM, for example. (IBM has a lot more process than web-based startups).

amen

+1 for the above but if it is a business application and the data will be reported then I often look at the reports to be generated and ensure all the data has been captured or is there anything that should be set by the system to aid in the report generation

henryporter

Depends on the project, but the last thing you should do regardless of project type is to lash into coding, because you'll end up doing a lot more coding and refactoring than necessary. You should follow some form of development process, whether it be Waterfall or Agile or somewhere in between. Regardless of which process you use the concept is pretty much the same - analyse requirements, write a spec, design a structure and a look for the app, code, test, integrate, test and then finish or go back a few steps depending on the model you're following. If the projects are for yourself then its up to you how to approach them, however if its for a paying customer you need to fully comprehend their requirements, and that normally they will change their minds before you get too far.

fergalr

krazyklown wrote: »

Bit of an airy-fairy question but i have two or three projects in my head but i cant seem to get started! like all hackers i just want to get down and start coding but i know i should be planning first but how do you kickstart the process? do you visualise the end result and try and work backwards (using pen & paper doodles?) Do you work from the GUI first and then work out the implementation or the other way round. What about test-driven development, i was looking at a few tutorials on that!

There are a lot of different approaches to software engineering. (Maybe read a couple of books on them). But the right approach depends on what you are building, and the state of technology.

If you were building a web app a few years ago, you'd maybe mock it up in photoshop, and show it to a sample of prospective users. Then produce a spec, iterate, and eventually start building.

But now, its probably quicker to hack together a prototype on app engine or rails, put it live on the net, publicise it, and see what bits people love/hate.
You can then fix the bugs, develop/cancel features as they become important/unimportant.

If you are building triggering mechanisms for thermonuclear warheads, you don't build fast prototypes in python, connect them up to the nukes, and see if there are bugs.

Instead, you spec everything out, carefully, in triplicate, go very waterfall, have loads of code review, and an independent team check your work before you go *near* production.



There are a lot of ways to do software development wrong; these are worth learning and avoiding.
There are also patterns that people use that make sense to solve certain problems.


But there is no 'one size fits all' approach, that works regardless of budget, task, technology, and domain.

krazyklown wrote: »

Is there an industry standard approach,

There's no one standard approach.
There are many approaches, and variants.
Don't get me wrong - there's lots of commonality - but there's no single answer.

krazyklown wrote: »

i learned about development cycles (incremental, waterfall etc) in college, are they used much?

Yes. What is used depends on the organisation, but most organisations have some sort of process, or set of processes.

krazyklown wrote: »

Or is it a case of just start coding and keep refining it until you are happy?

Sometimes this is the best approach too. But there's better and worse ways to hack prototype stuff together.

krazyklown wrote: »

Any links or templates that would help guide me would be appreciated!

I'd say go read lots.
'The Pragmatic Programmer' is good.
'Rapid Development' is good. 'code complete' also, but its lower level.

Loads of great software eng books out there, and loads of websites listing great soft eng books.

_tony_

I find that the approach to use really depends on what your looking to do. Typically my projects fall into 2 main categories:

1. I know exactly what needs to be done, I could write a rough spec of everything I need to do (typical business-case). Granted as you develop your project things will change, as you interact with a customer things will also change, but I could at least make a good initial stab at a design.
2. I have an idea I want to try out - I know roughly what I want the final product to do, but maybe I don't have much experience with this product type and am unclear about the technical design or what hiccups may occur. Maybe I'm even unclear about what exactly I'm setting out to do. But I'm eager to try something out!

For situation #1, I'd use a typical business (agile or waterfall) style approach as these would be developed with several other people, for a paying customer.

For situation #2, these would be more hobby or startup projects. These are much more flexible as I'm not developing for someone else. The best way I find is to try to get a full week that you can dedicate to it - and give yourself that week (night and day) to make some crude, cut corner, badly designed, early alpha version. After the week, release it or show it to people to get opinions. Then I'd, take a few days off development (very important), and do some top down thinking about the project - often it will be best to redesign from scratch, identify where is the value, how much will people pay for it, market size, etc.. Spend as much time as necessary on the design before starting the real development.

The purpose of initially diving into development is to help you understand the project your setting out to develop. It's only after you have a better idea about what your trying to do can you really come up with a good design, and also it often helps identify the priorities of different components from a business perspective.

Anyway, after the design is made, identify what's your minimal viable product (probably scale back the design), make a timetable for the development work and stick to it. Never break your deadlines.

The worst thing you can do is dive in to development from scratch and never look back. I cannot emphasise how important it is to take a few days off completely after the initial spike to have a good think about the project. After a real design and timetable is made up, I try to avoid using source code from the initial spike. Avoid getting into the loop of endlessly refactoring a bad initial design - time is money!

After every public release, take a couple of days off, reflect, and plan what's the next significant step for the project you need to focus on!

One final tip is to try to split your interest in technologies from what's most important for your project. A bad game with great graphics is still a bad game. A bad website which has great shopping cart is still a bad website.

Good luck!

krazyklown

Cheers lads, i appreciate all the replys and everyones insight. I appreciate that there is no one magic answer but it helps to get an idea of how different people approach their work which was what i was looking for!

Korvanica

1. Decide on what you want to do/create
2. Write down some bullet points that describe the application
3. Decide what the main classes/objects you are going to need
4. Code up a basic structure with some functionality
5. Add more functionality one piece at at time testing each part as you go.
6. Design and create a GUI and integrate it with the application.
7. Fix Bug
8. Test
9. GOTO 7

Dave!

OP you might find this talk interesting/useful. A developer going through the development stages for his company.

http://how-i-work.com/workbenches/4-ui-app-dev-with-vim-rails-and-a-little-photoshop-on-osx

krazyklown

Dave! wrote: »

OP you might find this talk interesting/useful. A developer going through the development stages for his company.

http://how-i-work.com/workbenches/4-ui-app-dev-with-vim-rails-and-a-little-photoshop-on-osx

Cheers Dave, finding that very informative!

henryporter

Dave! wrote: »

OP you might find this talk interesting/useful. A developer going through the development stages for his company.

http://how-i-work.com/workbenches/4-ui-app-dev-with-vim-rails-and-a-little-photoshop-on-osx

+1 - very informative; that fellow makes it look very easy altogether; in fact I learned as much there as I did in an entire semester of web development!