How do you write an application?

[Matt Kidd]

(I didn't know where to put this so I guessed here since this is the closest to software methodology here at javaranch)

Thats a pretty plain jane question isn't it....and pretty wide open since I could easily be talking about a "Hello World" application...but I'm not. I'm talking about how does a piece of software, for example say Firefox, Thunderbird, or any other downloadable application, go from being an idea to a design to code and something actually usable.

I had a software engineering course in school but that was Spring of 2000 and the industry isn't anywhere the same (I'd even argue that is changed quite a bit right when I graduated but thats a rant for some other time) and even that course didn't stress actual coding of the system we designed. So as it stands I have a CS degree without having written a large program (probably not to uncommon in the late 90s....I hope). I'd like to change that.

Now i have a few ideas for stuff I'd like to write, with on in mind in particular, but I don't know how to these ideas to actual production code. I'm thinking of the methods and ways to accomplish particular tasks but I'm not bringing it all together.

What I"m looking for is a step-by-step process that hopefully doesn't get muddied with the new methodoligies like XP, even though that would probably make me more current I'd rather save that for the big project I have in mind.

[Steven Bell]

I think that's the million dollar question. There really is no 'way' to write an application. The basic steps are to gather 'all' the requirements, what it does, what it looks like, what is it's purpose, identify the problem. Then break that problem down into pieces, break those pieces into pieces, until you have small enough peices to work with. Build the small pieces and pull them together. (As you break them down you would need to identify how they will interact, Interface, messaging, whatever).

One thing I think nearly all developers have found out the hard way is that getting the requirements right can make or break the app (or at least be the cause/prevention of alot of headache).

[Karen Baog]

Scope your requirements. Draft a Software Requirements Specification.
To start with, the top-level requirements are extracted from the contract.

[Ilja Preuss]

Originally posted by Steven Bell:
One thing I think nearly all developers have found out the hard way is that getting the requirements right can make or break the app (or at least be the cause/prevention of alot of headache).

Paradoxically, what many also have found is that it's nearly impossible to get "all the requirements fully right" before starting to code.

[Ilja Preuss]

Originally posted by Matt Kidd:
I'm thinking of the methods and ways to accomplish particular tasks but I'm not bringing it all together.

Tell us more about that: what are thinking of, and in which ways do you struggle with bringing it together?

What I"m looking for is a step-by-step process that hopefully doesn't get muddied with the new methodoligies like XP

Not sure what you have against XP. One step-by-step process I know of is ICONIX. Sadly, I don't know wether there is a good description of it available.

Anyway, there is only one thing that I think really applies almost universally: every successful big project started as a successful small project.

[Matt Kidd]

Originally posted by Ilja Preuss:


Not sure what you have against XP. One step-by-step process I know of is ICONIX. Sadly, I don't know wether there is a good description of it available.

Anyway, there is only one thing that I think really applies almost universally: every successful big project started as a successful small project.

"Tell us more about that: what are thinking of, and in which ways do you struggle with bringing it together?"

(for some reason that part didn't quote)

Take my calculator app I want to do for example. Conceptually I can figure out the interface and how I want to have a basic calculator then add additional functionality like trig functions and converting of degrees or math in over degrees like radians. Then I learned there are multiple ways of computing pi so I thought about adding that as a cool little visual (just click a button and watch them go see which is faster sort of thing). Well now that I have this interface I get stuck connecting it to the logic but the logic I can figure out sort of in that I know that I'll need methods for multiplication, figuring out a square root, or raising a variable to a specific power. But I can't get how to get from the interface concept to the coding of the actual logic or how its all packaged.

Actually I think that may be it. I recall my advanced OOP course I had that I got completely and totally lost with how it was packaged. I didn't know what was where as it seemed to me that the program could start in any of 3 files and there was a lot of redundancy (my memory is bad forgive me...I'm probably making myself sound better than I actually was) with the way it was packaged and generally didn't make much sense. It also probably had to do with how for everything I've coded I've gotten a grasp of how the whole thing works before I started coding usually using some UML diagram.

As for XP, I have absolutely nothing against it aside from it being this big huge black box that I don't know what is inside of it and appears to be completely and totally unweildly. Yet I'm sure once I sit down with the book I have at home I'll realize its just another software cycle like waterfall or spiral.

I hope that gave you a better idea. I'll go looking for that ICONIX too.

[Warren Dew]

Matt Kidd:

Well now that I have this interface I get stuck connecting it to the logic but the logic I can figure out sort of in that I know that I'll need methods for multiplication, figuring out a square root, or raising a variable to a specific power. But I can't get how to get from the interface concept to the coding of the actual logic or how its all packaged.

Possibly what's missing here is that there is a whole layer of code that deals with the user interface, and not with the functionality.

If you want a graphical program, you might try picking up a Swing book and trying an example from it; if you want a web application, you'll need to create the HTML and write code to parse input from the user and convert your output into an output page. Often there's more code involved in the user interface than there is in the core functionality.

[Stan James]

You might take a look at Ron Jeffries' Adventures in C# (It's close enough to Java that you can read it.) It's essentially a diary of building an XML editor. I've read some installments on his website (http://www.xprogramming.com/xpmag/acsIndex.htm) that were very interesting.

Robert Martin's Agile Software Development has a neat case study building a payroll system that should give you some ideas about getting requirements up front and evolving as you go.

Both of these have a sense of watching over the master's shoulder. Certainly one way to learn something.

[Ilja Preuss]

Matt, if I understand you correctly, your main problem is with how to structure your code?

If I got that right, I highly recommend the book Stan already suggested. It discusses the forces, principles and practices behind OO as a tool to structure your code at great length, with many examples.

[Matt Kidd]

Ilja, which book were you speaking of?

[Ilja Preuss]

Originally posted by Matt Kidd:
Ilja, which book were you speaking of?

Robert Martin's "Agile Software Development": https://coderanch.com/t/93457/Book-Reviews/Agile-Software-Development-Principles-Patterns

[Lasse Koskela]

I'm pretty sure Ilja is referring to Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin (which is indeed a great book for explaining some practices and principles for implementing good object-oriented designs).