Hm. I'd say I have about a 70/30 split of maintenance to development. At my workplace, all of the business tools in use were coded by the company's first programmer, who left earlier this year. Since the company needed a programmer suddenly, they simply asked him to learn how to code on the job, and from there he developed the programs to run most of the operations here; however, since he was essentially an amateur programmer, there's quite a few design flaws.

The biggest problem is that he didn't future-proof anything he coded, though it's understandable, as he probably didn't know how to future-proof as it was. As such, I spend a good bit of time refactoring his code and making sure it can work with our migration of data from Microsoft Access to SQL Server. In some cases, this is rather unpleasant; the C# interface that runs most of the basic tasks for the business is about 30,000 lines of code, and there's two comment "blocks" (just a sentence each!) in the whole thing. Figuring out exactly what he coded and how it works is... Complicated, at best. Especially when he used the oh-so-fun naming convention with object b having property a, and so forth, so large stretches of code turn out to be just random mishmashes of single characters. Rather tough to handle at times, but I've managed decently so far 🙂