The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Need some pointers on the process of development

Hi, I'm a bit of a newb when it comes to programming.  I've got a question about the process of software development.  What general steps do you follow to get from the start to the end?  I sometimes get ideas for stuff at work but I stall out (I think) because I don't have a good process for taking things from concept to implementation.  It just seems overwhelming and I don't know where to start.

Let's say you've been tasked with creating a windows based CRUD app, a help desk trouble ticket system for example.  Oh, and you're working alone so you have to do everything yourself.  Ok, I know I'm going to need a database of some sort.  But at what point do you start deciding on tables and their fields?  Assume you're using an object oriented language for the application.  So, do you start thinking up objects, methods and fields first?  Do you just kind of bounce back and forth from the code to the database adding whatever you need?  That seems like hacking?

Any book reccomendations?

Thank you

(and no, this is not homework!)
Friday, June 30, 2006
Are you in the situation you describe? What is your background to be a newb and yet get this sort of task? Did you recently graduate? More info would be helpful here.

The short answer is that you just gotta pull through and do it and it gets easier later. It's helpful to have a mentor, or to have things ramp up more slowly, but you might be able to handle the challenge you described, you gotta try it and see.

Which way to do it, you can try it one way and it is a mess and you do it a different way later. Then, next time you do it you overdesign - the 'second system effect'. I do recommend reading some things to cope and deal, like Peopleware and Code Complete, just as general personal development.
Art Wilkins
Friday, June 30, 2006
"Do you just kind of bounce back and forth from the code to the database adding whatever you need?  That seems like hacking?"

That's why good programmers are called hackers.  Get used to it.

Especially when you are a beginner, you start with the simplest thing that could possibly work.  No more.  Get it working.  Then try to add the next thing.  You will have to expand your code, reorganize it a little probably, to accomodate both features.  Then add the next thing after that.  If some code duplication creeps in, think about how to eliminate it, and what it implies about the organization of your code.

Keep repeating.  Mix in a few years of experience to cut down on the false starts, blind alleys, and messes that need to get cleaned up, and that's programming.  The process is never pretty.  Ever.  But the final result can be with a lot of work and patience.

Friday, June 30, 2006
One approach is just to implement the simplest thing which works, then keep adding to it. This doesn't have to be done in a 'hacky' way - do some googling on agile development, XP, iterative development etc.
Friday, June 30, 2006
Well, I kind of worked my way up to a DBA job title.  I was a server support guy and then the DBA quit so I volunteered to try and do his stuff and it's been working out fine for a few years.  So they gave me the title and the salary even though it's not a real hard core DBA job.  You know what I mean?  It's one production Oracle database for a client/server app.  I don't have anybody logging into the database creating tables or anything so it pretty much runs itself. 

So now, I'm back in school at night part time getting the bachelor's in computer science.  I want to get into software development.  I've had two chances to make CRUD web apps for our department but they did not turn out that great.  The ticket thing I mentioned above is just hypothetical.

This is a tiny IT group in a small department in a large company.  And I don't know why but I got Peter Principled up to DBA and now I'm just trying to get legit as an IT professional and a software developer in particular.  The school I'm going to is not exactly Stanford.  It's a night school for working people.  They are teaching general concepts and not specific vendor technologies so that's good but we just didn't spend much time on this in the programming classes I've taken so far.  We did some UML story cards in the algorthim class but that was it. 

Friday, June 30, 2006
I think the only way to make something well is to have made something poorly in the begining :)

But, for a web-app, it's often easiest to break down features; those features define the information requirements, which determines the schema. Then you can figure out the workflow; that determines the code that manipulates the data in the schema.

Of course, it's an iterative process; workflow/performance will make you modify the schema, etc...
PHDude Send private email
Friday, June 30, 2006
"The school I'm going to is not exactly Stanford.  It's a night school for working people.  They are teaching general concepts and not specific vendor technologies"

At good schools, the don't teach you languages, they teach you concepts. It's generally accepted that if you're any good you can figure out the languages yourself.
PHDude Send private email
Friday, June 30, 2006
I would begin by drawing the app on paper. Literally, every screen that you can think of should be rudimentally sketched out. (It's much easier to change and will give you a good visual representation at once of the entire schema.)

Then, when you have an idea of how the user will go through the app you will begin to see a need for certain database information.

For instance, you'll see that you need a login. What's required with the login?

UserID (autonumber and primary key)
First Name
Last Name

Right there is your first database table.

Then you say it's a trouble ticket system. So here's another table:

TicketID (autonumber and primary key)

Now you know what user is assigned to which ticket. From there you can already see how the screens allowing for the creation and editing of the tickets by the users matches the fields in your database.

Obviously I simplified things, but that's how I'd start.
Yoey Send private email
Saturday, July 01, 2006
As far as book recommendations, check out Code Complete:

As Joel recommends, "The encyclopedia of good programming practice, Code Complete focuses on individual craftsmanship -- all the things that add up to what we instinctively call "writing clean code." This is the kind of book that has 50 pages just talking about code layout and whitespace."
Yoey Send private email
Saturday, July 01, 2006
Your school is good enough, they are focussing on the right things. I think you are taking the right approach. You are doing fine. It seems scary until you've done it a few times, but yes, most design is screwing around until you find something that works, then making it so you can repeat that next time even better. Eventually you become a master, but only if you are committed to keeping up with things. Code Complete will help. Keep an eye out for well reviewed books. There is this thing called refactoring that means before you start adding new features to the big mess you call your code, you clean up the old code to not be a mess so you have something more solid to extend. The  trick is to do this without breaking it. So to do that you have to first write a set of automated unit tests that verify the code works so that when you refactor, you can test continually, like after every change of a line of code, to make sure you didn't break anything. The book that makes this technique a science is Refactoring by Fowler.
Art Wilkins
Saturday, July 01, 2006
"most design is screwing around until you find something that works"

No, what your describing is the how to write software without design at all.

It is possible to first think everything through, and then to start coding. Start with the GUI. Then think about the database layer. Then decide on high level design issues such as MVC, etc. I'm not talking BDUF here, but just thinking things through is a good idea.

TIP OF THE DAY: Download the SPEC Joel wrote for his interns last year. Think about the stuff he describes, and write something similar for your own product. Writing things down is a lot more useful than just keeping it in your head, because you always get new ideas as you're writing.
Saturday, July 01, 2006
Dude, once you know what works, then you can stop screwing around and do the design up front. But if you've never done it before and you don't have a mentor and you don't have a degree, then you are going to have to experiment and gain experience before you can sit down and come up with the correct design a priori.
Art Wilkins
Saturday, July 01, 2006
"Plan one to throw away; you will, anyhow" -- The Mythical Man-Month.
Alyosha` Send private email
Saturday, July 01, 2006
"It is possible to first think everything through, and then to start coding."


And I'm taking up piano next week.  I think I will start by composing a piano concerto from beginning to end, envisioning the 52-piece orchestral arrangement in my head as I go.  Otherwise I'll just be hacking around.
Saturday, July 01, 2006
Hi Newb, just by having a desire to "get legit as a professional" you are ahead of the pack compared to a large number of cubicle dwellers out there.  Anyway, Steve McConnell books as recommended by other folks are practically required reading.  i like his Rapid Development as well, especially for the anecdotal case studies, since it seems like you are a one-person army this may make up a little for the lack of peers/mentoring that you have available. 

Also, dont forget about the end-user, who somehow seems to be missing from the dream of coming up with a magical design by sitting there and thinking really hard about it.  Itd probably be more useful to take the time to find out how users will need/want to interact with the system, ie. use-cases, unless you have the ability to read their minds or dont really care about what the end-user thinks.  PS. just because the language youre using is object-oriented doesnt mean your dept-level CRUD web app should be, esp. if you are a newbie who needs to learn the basics.  good luck!
Sunday, July 02, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz