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

The horror: Sysadmin needs to do dev work

... and I am the system admin in this case, and I need some advice from the JoS community.

I created this proof-of-concept, quick and dirty small web application in C# and the orgininal plan was to turn it over to some in-house developers once everyone had a chance to comment.

Well, now, no one is availble to work on it so I have to try to build this thing correctly over the next couple of months. And I really don't want this code to end up next year, so I would like some advice on finding books, blogs, or any other source for recommendations on how to do it in an easy to maintain, relatively standard way.

I can find a lot of big, all encompassing, how-to guides but they place equal emphasis on the uses of C# and advice for web-based applications is often mixed in and hard to find.

For background, this paticular application will consuming a lot of web services from existing interal apps, will have ultra simple database connections, and will be running in pure microsoft environment.

Thanks for any input
Matthew Damp Send private email
Thursday, May 14, 2009
You can read all the books and blogs you want, but the best thing to do is just do it and learn from your own mistakes.  It'll be ugly, but so what?  The first major app or project that anyone does is ugly.  You can stop and try to refactor along the way, and possibly get some involvement or critique from your inhouse devs, but if you focus too much on doing it the "right way" you'll never get anything done.
Jason Send private email
Thursday, May 14, 2009
I agree with Jason, in order to learn how to build good software you must invariably build some not-so-great software first, it's just how the learning process works unfortunately.
Julius Seizure Send private email
Thursday, May 14, 2009
"...And I really don't want this code to end up next year..."

If it works nobody will care.  You will, however, probably have to support this thing for the rest of your life.

You won't get it perfect the first time out.
Almost H. Anonymous Send private email
Thursday, May 14, 2009
Go ahead and work on it.  Then read Code Complete for ideas on how to improve it, and Refactoring for ideas on how to implement those improvement ideas without breaking it in the process.
Kyralessa Send private email
Friday, May 15, 2009
+1 for Code Complete. Better to learn from someone else's mistakes. And he covers the basic stuff like "off by 1" errors  ("Did this loop start counting 1 to N or 0 to N-1?"). 

It's easy to read an very practical.

Take a look at Joel's reading list (or any reading list that includes Code Complete).
Mr. Analogy Send private email
Friday, May 15, 2009
Also pick up 'The Pragmatic Programmer'. That along with previously mentioned 'Code Complete' will give you a great primer on good, modern developer practices.

I fundamentally disagree with the notion that you should just "start coding, learn from your mistakes". Knowing about practices like source control, automated testing, defensive programming etc will save you lots of grief down the line.
Thomas Kjeldahl Nilsson Send private email
Friday, May 15, 2009
You'll be fine, judging from the fact that you are already concerned about your work.
darkt Send private email
Friday, May 15, 2009
One bit of advice against doing something I've seen too many SA's do:

Don't make system calls to run a quick a different program just because it solves a problem a little bit easier.

Also, leave comments on what you're thinking and what you're trying to do.  When you're first starting out, your style will be a bit weird.  A year from now when a more seasoned programmer looks at it (and this may be you), they'll be confused why anyone would set things up that way.
Lance Hampton Send private email
Friday, May 15, 2009
Can you ask a dev at your company to be your mentor for the project, or at least take a look at what you're doing periodically?

That way you get good feedback, your mentor gets good leadership experience, and your company gets a better product: everyone wins! 

(Okay, "everyone wins!" sounds a bit cheesy, but it's true.)
Christopher Svec Send private email
Friday, May 15, 2009
the best rule of thumb i've ever heard is "start refactoring on day 1".

write something, get parts of your app working, and continually work to make it better.
jdt141 Send private email
Tuesday, May 19, 2009
There are lots of suggestions on Joel's site. However, as someone suggested, just get going as if you try and understand everything at once, it will be overwhelming. As you go along, re-read some of the articles pertaining to software development and see if you're ready to apply the idea.

However, at this stage I would suggest that you take the time to write down a requirements/specifications document. This can be as simple as an excel spreadsheet with one written description of a requirement per cell. The purpose of the document is not to write down in stone a complete and accurate specification of what the final product will be -- it is to clarify the communication with the user (who might even be you) of what you perceive the product to do.

This can save you a lot of time as you may find that you had a lot of miscommunication with the user (once again, that might even be you) about what the program should do -- and it's faster to rewrite an excel cell than to rewrite a code module.
Larry Watanabe Send private email
Wednesday, May 20, 2009

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

Other recent topics Other recent topics
Powered by FogBugz