Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As a young developer, I would find it useful to get some advice regarding things to think about in order to develop a high-quality application. In my college courses, most teachers emphasized input validation and some talked about security concerns, but no one covered the importance of certain other things, like logging for example.

What are some mistakes that inexperienced developers tend to make which could lead to frustration for more experienced developers?

share|improve this question

closed as not constructive by Mark Trapp Oct 25 '11 at 21:32

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I wouldn't exactly call security something to go on a "checklist" -- security must be considered at all levels of a design, not added on as an afterthought. Security features != secure features! –  Billy ONeal May 29 '11 at 6:55
    
Maybe "checklist" implies the wrong thing. I'm not looking for a list of things to think about at the end of development; I'm curious what things should be considered as you're developing an application. Do you have a suggestion for how I could restate my question? –  awmckinley May 29 '11 at 7:08
    
@awmckinley: Then your question is "how do I develop an application" -- but that question is too broad to be answerable. –  Billy ONeal May 29 '11 at 7:15
    
@Billy ONeal: Just edited my question. Does this make more sense? –  awmckinley May 29 '11 at 7:44
1  
It makes more sense, but unfortunately it's still not asking for much more than a laundry list of best practices. Constructive questions really should be about specific problems, or at least require answers to be more than one-line opinionated quips. –  Aaronaught May 29 '11 at 17:36

9 Answers 9

  1. Tests.
  2. Tests.
  3. More tests.
  4. Source Control
  5. Taxes appropriate to whatever program you're targeting.

On Windows, these taxes are:

  • Dealing with High DPI environments
  • Roaming User Profiles
  • Fast User Switching
  • Remote Desktop (e.g. you don't want to use double buffering when RDP is in effect
  • Playing nicely with Hierarchical Storage Management
  • Multiple Monitors
  • 64 bit Windows

On pretty much every platform, you'll have to deal with:

  • Unicode
  • Localization
  • Power Managment
share|improve this answer
    
I'm sorry, Billy. Maybe I wasn't clear in the way I asked my quesiton: I'm not looking so much for development practices (like source control). I think that was pretty well covered in What would you add in this Software Development Project Checklist?. The "taxes" section is definitely helpful though. –  awmckinley May 29 '11 at 7:18
3  
@awmckinley: The reason I bring up source control is that you won't be able to manage releases effectively without being able to have multiple heads of development -- even if you're only a solo developer. You need to think about release n + 1 even when you're working on release n. –  Billy ONeal May 29 '11 at 7:35

Really broad question; to answer in detail is ...multiple books.

Here's a general systems-definition checklist to get you started -

  • What are the critical resources in the system and how might the demands on them change?
  • What are the performance capabilities of the system and how might they need to grow?
  • Which areas of requirement might become unnecessary and removable?
  • Is there the possibility of a need to have different versions of the system with different capabilities?
  • What are the implications on manpower and computer resources if the identified changes come about?
  • What impact will the new system have on existing operation systems?
  • Which areas of function have the greater chance of requiring change in the light of experience with the system?
  • Who are the system’s future users?
  • What are the system’s future maintainers?
  • What are the future enhancements that the system’s future users can identify as likely?
  • How does the system fit into the user’s overall plans and how are they expected to develop?
share|improve this answer

In my experience, the one thing nearly all inexperienced developers fail to bear in mind is that you're (almost always) working in a commercial environment. Your code has to be good, but not perfect. The most important thing is not perfection, it's that your code ships.

Put another way, delivering the perfect piece of code three months after your company has gone bust is no good to anyone.

In my opinion, this is one of the most significant ways in which development in the real world differs from development as taught at university.

share|improve this answer

Because you asked the worst things, then my answer is as follows:

  1. Forgot to think of sanitizing the development machine from spywares, malwares, and trojan viruses.
  2. Forgot to think of making a regular backup saved in secure storages that are in different geographic locations.
share|improve this answer

I find the main thing new developers forget is that in the real world they are often working as part of a team. This shows itself as..

  • Checking in code that breaks the build
  • Not reusing code that's already there
  • Doing things their way rather than the same way as everyone else - which makes maintenance expensive

That's not to say their code isn't up to scratch in isolation, but they aren't working in isolation anymore.

share|improve this answer
    
+1: fundamentally, these are the issues you face. Junior coder may be poor at coding, but then some experienced ones are poor at coding too. The main distinction are items like these. –  gbjbaanb May 29 '11 at 14:42

The clean decoupling of the system on one's development machine, and the target machine, so that one does not end up with "Well, it works on my machine" situations.

And how quickly can you reconstruct your development machine?

  • Do you know which packages you requires?
  • Do you have a push button solution to rebuild your database?
  • Do you have a push button solution to test the integrity on the source code?
share|improve this answer

I think its probably design - ie the approach of thinking about what you're going to do before you do it.

Too many inexperienced coders (remember when you first started) like to jump in and get something going, then add a bit more and ad a bit more and add a bit more. This approach can work if you've planned to do it that way (each bit can be tested as you go after all), but most inexperienced coders only focus on the part they're writing.. so all the additions tend to be hacked in on top. And we've all seen code that's evolved like that!

Organization is the next thing, often they're too focused on the code they've written to remember how they did it, and what was required. So they forget to bundle or document a dependency that's required. They also tend to put things where they fall, I had to criticism a junior last week who checked in his code in the root directory including 3 wsdls, 2 of which were the same file, and a set of 3rd party dlls which he committed in a sub directory and the root directory. The code wasn't formatted to any standard you could think up either, and there were several functions that were present but never called.

Obviously he got it working but it was not tidy, and that meant installation, and maintenance, would have been troublesome.

share|improve this answer

My biggest one is remembering to plan for flexibility. In classes, the requirements are almost always set forth at the beginning and never change. In software, it's often the opposite: you get a vague set of requirements, and they change often (even daily). The best thing that you can do to help with this is to code flexibly: loose coupling, small functions that can be used reliably in multiple situations, and avoiding hard-coding things as much as possible.

In time, you're likely to learn a) what things are most likely to change, and conversely what likely won't, and b) how to anticipate change requests and plan for them.

share|improve this answer

I think the biggest differences are in the coding technique. Everyone has a slightly different approach, but inexperienced developers tend to produce code that:

  • does not handle boundary cases
  • is far lengthier than necessary
  • has bad performance characteristics in relevant scenarios
  • has poor separation of concerns
  • lacks self protecting techniques like use of const, sealed, readonly, etc.
  • oddball ways of returning data and collections of data
    • this more demonstrates inexperience with a platform
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.