Fog Creek Software
Discussion Board




Making (design) decisions

I am working as freelance Java and PHP programmer from home(31 years old). I have a masters in CS and code software for a living for 1 1/2 year now. Often I run into
problems on design decisions or which tools/libraries I should use. Sometimes I dont even know how to start a software project. I am doing fine on smaller less complex projects. But bigger projects or complex systems give me a headache (Ok, programming is not rocket science). May be I am missing some experience ? Or is it just "some people dont get it" ? I really want to become a better architect and programmer (time is ticking).

So these questions are basically for other freelancers. How do you make decisions on software when you dont have other people around you that are more experienced. I personally try to use newsgroups, read books (Pragmatic Programmer, Design Patterns, Code Complete, etc.), try to ask questions on IRC in specific channel like #java or #php and surf the web (www.javaworld.com, etc). But I think that's not the same as working in a company with experienced people and it is very very time consuming. What are your strategies ? Have you started a user group so you can discuss technologies with other people ? Are you joining conferences about programming ?
Thoughts ?

Kai

Kai
Thursday, February 28, 2002

> I personally try to use [...] But I think that's not the same as working in a company with experienced people and it is very very time consuming.

I did just the same as you (Compuserve, in those days) working in a company without experienced people: and it too was very very time consuming.

So IMO you have a good strategy already; get experience.

> I am doing fine on smaller less complex projects. But bigger projects or complex systems give me a headache

A headache is a medical problem.

Bigger problems or complex system are accomplished by using interfaces (also clean code, version control, peopleware, reliability and all that).

> problems on design decisions or which tools/libraries I should use

I'm coding in C++. If you're using Java the language, it ( http://www.amazon.com/exec/obidos/ASIN/1575211297 ) seems much like C++ except for its memory management (and libraries, and IDK about JNI and security) so for all I know you're OK with Java except for real-time software.

Libraries vary over the years (new ones are written), so no general advice there except to choose ones which work, are affordable, and suit (help you to write) your application.

> May be I am missing some experience ? Or is it just "some people dont get it" ? I really want to become a better architect and programmer (time is ticking).

IMO it took me a year just learning plain C++ (my 5th or so programming language, excluding document markup language) and Java isn't much less complex than C++.

> So these questions are basically for other freelancers. How do you make decisions on software when you dont have other people around you that are more experienced.

In my situation, employed with similarly experienced peers, I decided to make decisions "any way I can" (my boss tells me to do it, I figure out how to do it any way I can).

And on the newsgroup[s] I ask 'technical' questions.

Christopher Wells
Thursday, February 28, 2002

It's primarily an experience thing.  18 months is not a long time at all, so if you're feeling the pressure of the clock now, relax.  Experience teaches you by presenting you with enough situations that any given situation will usually look something like a previous situation, so you apply what you learned there to the current problem. 

So, vary your tasks enough that you gain as broad a range of experience as possible, and design issues will become easier.  But don't expect progress overnight.  After 20 years of coding, I still find new problems, new approaches, and sometimes get stumped.  That's what keeps the job fresh and interesting.  Personally, I attack things by actually writing code, which I consider disposible.  Lots of fits and starts, but it works for me.  Others won't write code until they have a better idea of where to go, perhaps diagramming or whatever.  Horses for courses, and you'll eventually find what works for you. 

Finally, focus on actually solving the problem, but don't worry about optimal solutions, or correct code, or perfect designs.  Just make the damn thing work.  Software evolves, and first designs will always teach you what you did wrong. 

James Montebello
Thursday, February 28, 2002

If it's language or lib choice, I usually run the basic project description past a friend or two whose technical opinion I trust and see what they come up with without hearing my proposed solution. More often than not they validate my approach, but get me thinking about it in a different way, and that's a good thing. Of course, this all depends on having a couple of friends whose technical opinion you trust =)

Alex Russell
Friday, March 01, 2002

Don't sit in front of a computer.

Code happens when you sit in front of a computer.

Design happens while you're sat in the park.



Companies don't realise this which explains the HUGE amounts of (usually duplicated, usually broken) code they have and the vast lack of design..

Katie Lucas
Friday, March 01, 2002

I have relatively little problem coming up with designs with which I'm satisfied.  But then, I've been programming for almost 20 years.

Here's my tip.  You've read some pretty good books.  What you need now is practice.  Try this.  Go through the Java Tutorial on Sun's website.  Whenever you find a link to source code, don't download it; instead, try to write it yourself.  Then download and compare.

Expect mistakes.  You gave this variable an ambiguous name.  You implemented that graph traversal too inefficiently.  This thread you wrote is busy-waiting.  Et cetera.  These are good mistakes, because you'll no doubt remember them, and derive useful experience from them.

Katie does have a point; design is what you do when you're staring at the ceiling with your hands off the keyboard.  However, I say that's of limited value at first, when you don't know what to come up with.  Diving in and coding, and making mistakes, will serve as a guide later when you're in the park.

Paul Brinkley
Friday, March 01, 2002

"I really want to become a better architect and programmer (time is ticking). "

While these things aren't completely disassociated, the areas you have to focus on for improvement are different.

If programming is your focus, then I agree that diving in, coding, and experimenting with the things you have read will go a long way to helping you improve those skills. 

If architecture is your focus, it takes a bit more.  When you are looking at design, the biggest question is whether or not what you are considering is an appropriate solution.  This means that you need to understand the system you are building and the requirements associated with it.

You say that you are having more problems with complex systems.  Have you broken down the functionality?  Can you compartmentalize it and then deal with each compartment as a smaller, less complex project?

As to where to find information, there really is no substitute for personal experience.  Regardless of the books that you read or the people that you talk to, it isn't going to be meaningful information until you have had the chance to apply it and evaluate its success yourself.

!
Friday, March 01, 2002

Out of interest,

How do you become a freelance programmer?  Where do you look for work?

My eventual goal, after I've gained enough commercial experience, is to freelance.

Any good books/sites/etc that could show me how to get started?

Ged Byrne
Friday, March 01, 2002

ERDs (Entity-Relationship Diagrams) are a good start to any good design.  Make the boxes, draw the lines, and set your blue-print for everyone to reference.  It is also helpful to have at least one other developer with you while you do this.

To me, technology decisions are already in place in most forms, unless there is someone with a large wallet ready to throw money down.  Don't get caught up in trying things you don't know just to have a chance to learn them when you need to be focused on the job at hand.

Are you capturing information that will be reported on?  A database will come in handy.  Are you surrounded by a bunch of VB programmers? Might want to consider a VB approach.  Need a function that will split out a delimitted string in a form post into an array?  Hit-F1, the oft forgotten, in a pinch, technology expert (with code EXAMPLES to BOOT).

The only other suggestion I have is to ask yourself if why you have trouble starting is because you are questioning whether or not someone else has done this, and if there is a "right" way to do this.  The only "right" way to solve the problem is to provide the solution.  Make sure you're not searching for the answer.  The answer is what is expected to happen by the person who is paying for you to deliver.

cg
Saturday, March 02, 2002

You might want to consider simply trying to describe your solution to the problem in English or psuedo-code and after doing a description, try to put that into code.

Walk through what you do and ask yourself if it does what you described in your prep. Also, if your code is hard to explain to a non-programmer, it can often be simplified. Perhaps it is more effecient, but the readability should come first, and the speed of the code second until the final draft of the code.

Masterlode
Saturday, March 02, 2002

Well you are in the right place to ask questions.

Always remember that as a "freelancer" delivering is important. So make design decisions that see you delivering simply and quickly. 

If you need some help with Java or architectural issues, feel free to ask me (via email). I will help all I can. 
Of course the other forums you are using are great too.

Regs, James.

James Ladd
Sunday, March 03, 2002

It would be trite to say that large systems are just agglutinations of small systems.  Its more true to say that large systems are built in much the same way as small systems.

You find the interfaces between processes and data transitions, you manage those interfaces.  for larger systems you may have problems of multiple inputs, multiple states, but they can all be decomposed into simpler units that behave as all simple units do.

Doing the dishes is a great place to design (I find the park too distracting), or car journeys or railways journeys.

Simon Lucy
Tuesday, March 05, 2002

*  Recent Topics

*  Fog Creek Home