Shay Howe has some good points and I look forward to hearing more from him in the future.
Having worked on a legacy system before and also having worked with some third party dregs that should never have been paid for I can tell you that maintainability is important.
Luckily with languages like c# it's not to difficult to achieve. OO principles and ideas like dependency injection should already mean that your code is neatly organised. Don't be afraid of creating new namespaces or solution projects if it means you can work out were your code is stored.
The biggest thing you can do to create maintainable code as mentioned in the article is to make things modular. Modules should have a single responsibility and they can be as abstract as you like. For example lets look at a DAL (Data Access Layer).
The overall responsibility of the DAL is database access. Inside the DAL we might create a repository pattern, each repository has a single responsibility of dealing with a specific table. Then these repositories may actually be created from a generic repository whose responsibility is not to care about the specifics of the object but to work as the access to the database.
Now I kept using the word "responsibility" there because if I know what class is responsible for what task then I know where I can fix the problem. Maintainability is always about what will your brain a couple of years down the line understand when you haven't touched this code since -enter finite number- projects ago.
It takes a shattered glass approach to building applications but these pieces do make up a mirror that later on you'll be able to look at and know exactly what it does.
If we write our styles modular, we keep them maintainable, and that allows us to make sweeping changes fairly quickly without much detrimental impact