Destiny of a Developer, Writing codes on other developers' softwares

In the first years as a developer I only developped my own programs. But then I changed jobs and I faced a new challange. Writing codes on other developers' softwares. If the previous developer implemets standards and had enough knowledge it was ok. Sometimes I worked with previous developer which was OK too. But the problem arised when previous developer was not around, or he was a newbie, or he hadn't got any idea of standards.  It's a kind of nightmare for a developer to put a brick on a terrible wall.

There are two ways you may follow in this sittuation.
1 - You can throw away the existing codes and build up a new perfect software
2 - You can look the sittuation as a money earning kind of thing and do your best on existing codes.

If you choose the first way, I may say you are brave. But according to my experiences it cannot be the best way. There are many other parameters should be taken into consideration to decide which one you should choose.

The most important parameter here is your employer. If the employer is not good at with computers ideal way is second. Don't even waste your time to tell the reality.
Here I got some question list showing how I decide what to do ?

1. Does employer have enough knowledge what you talk about
2. Is the code terrible enough to throw away
3. How long will you planning to work in this job
4. How long is your employer planning to use the software
5. Is there any integrations with other softwares
6. Is your role good enough to take this action (way 1)
7. Do you have time for this ?

I recommend the second way. Even though if you are planning to do it in second way, start a new program but don't tell anybody until you reach the halfway.  Whenever you mention it you'll face time barriers.

What are the obstructions you'll face with a previous inadequate developers code ?

• Wrong data structure
• Wrong connections
• I once faced a software written by a rookie who didn't know how to handle many to many relations, though there was a long string field to put the many relation IDs comma seperated.
• I saw one field holding two connections at the same time like first 3 characters are one relation rest is another connection)
• Wrong ID handling
• I saw character based ID fields
• Wrongly named ID fields (I couldn't find out which field related with which tables)
• Wrong normalizations / optimisations
• Keeping same data in 2 or more tables instead of relations. Which creates inconsistancy
• Codes may be away from object oriented
• Instead of writing a function or a class doing same job in different screens again and again. Like there are Insert and Update screens exactly the same but save functions written twice.
• Because of not knowing about Enumarations there may be absurd values you may not understand unless you dig the code
• Because of not knowing about DLL's same functions can be coded again and again in different programs.
• Unnecessary excess codes
• In an update screen, button_click event send data to save function and it can gather data and send to a web service, web service formats data and send to a stored procedure and repeat this cycle for insert screen. (Just put a parameter to save function to make the code simpler)
• Performance can be ignored
• To insert one line to database, reading all the table.
• wrongly typed SELECT statements
• I saw some nested SQL sentences with 3-4 levels depth.
• Away from code formattings
• No uppercase, lowercase formats of the code. (It makes really difficult to read)
• Simple, You can read "SELECT ProfileID, FirstName, LastName FROM Profile WHERE Birthday BETWEEN '01/01/1970' AND '01/01/1980'  You'll see SQL commands are in uppercase and easily read it. Try it with all lowercase and you'll see it's more difficult to read.
• Unnecessary complex architecture
• Sometimes showing your ability is unnecessary. You may know AJAX but if you are coding an admin screen, postbacks can be simple and fast.
• Unnecessary screens. If it's not desperetly needed, there is no mean to make 2 different screens for insert and update. Only difference is RecordID and SQL INSERT or UPDATE Command. You can handle it easily by using an IF statement. If there are 2 screens and you need to add a field, you may easily make mistake in one later. Less code, less screens are always preferable. For example I do all my different list entries in one screen by differentiating parameter. in this way I only do the screen once and I don't need to do same screens again and again. It is a real time saver. Also updates become very easy in this way