I've written (and still doing it) an application that is about 100,000 lines long (I know it's not the best measurement) so far in C#, .NET3.5 with database on SQL 2005 with about 2 million rows and 50-60 tables. I was the only one writing the code, creating database etc and it has many bad habits, noob mistakes, learning mistakes, shortcuts in code and so on. I was literally learning C# while implementing this in production, but the best part is it works. That application is used by 4-5 people in total and maybe in few years couple of more people will use it.

Would it be hard for external developer, or whole company to jump into the code add new features, fix bugs etc? And would it be fairly simple and not that expensive or would it be the opposite.

I'm asking this because I am being constantly under pressure of being too expensive and I have a feeling that they might try to kick me off and try to replace me with either new developer or whole company. I imagine it may not be so easy since i administer Exchange, SharePoint, Sql on 3 servers, support 50 users and code at same time but would like to know what are the chances that they take another guy and he knows what to do with it in fairly easy way.

So far I am saying to them that if someone offers you a better deal without knowing what I do, how things look inside, it's unprofessional (since I am the only one knowing our systems and Board has no idea about it, things they will tell to new guy, company will be way off to what I actually do) and in longer time it can be far more expensive (since they will most likely come for money when they find out there's a lot of things they weren't aware about).


Just to add some more information. I've been hired in company as normal employee to Administer systems and help users. In the meantime I found out one department was having 700 excel files to keep running his customers + couple of other excel files to merge it together. So they asked me if i can help and since i didn't knew how to program at that point I had to learn it. So I did. After having 45k lines and being finished with one department, and having another department in need (since they fired the guy who wrote their Access DB) i started writing application for their 2nd department. At this point crisis came and they cut my money in half, and told to start my own company (so they wouldn't have to pay for my life insurance etc). So I did, in my contract with that company it is written that i am supposed to finish application that I made, i have to fix bugs that come in a way. However for 5 pages long company contract there's only 2 lines about that application and rest is about me supporting them in terms of administrations, help desk etc.

The problem is that they want now to access total owner/author rights to my application and while I can say that what i wrote for them when I was employee is not 100% mine than I can say that what i wrote during my company to company deal is mine. But this is another discussion we're currently having with Board and it's partially related to my question.

Edit2: There's no documentation on code, and no unit tests.

19 accepted

My entire career I have been a maintenance developer.

  • The server infrastructure can run itself for months until the new staff has time to figure it out, especially Microsoft products. If you aren't manually tweaking itself everyday to keep the servers up, then the servers are probably taking care of themselves.
  • The code likewise will run itself for months before a crisis will happen-- if you are in crisis right now or every few days, this is the real threat to ongoing employment.
  • The crisis usually can be fixed by going in and carefully fixing a very small section of code-- one only need to read a few 100 lines of code, not all 100,000
  • A code base with one original developer is actually easier to maintain because the maintenance developer is studying your style of thought. When there were 6 developers, then there are 6 peculiar ways to do things.
  • Over the long run, all the techniques of legacy code base maintenance can be brought to bear (wrapping the code base in unit tests, etc)

Make yourself valuable by providing a continual stream of useful improvements and maintaining a high level of service.

To make yourself valuable by trying to obfusicate code or thwart the next team is unlikely to work. Most project owners can't evaluate the threat that the code base is unmaintainable by someone else (and can't evaluate the promise that it is!)


It's easy to jump into code if:

  • It's well written and architectured
  • Class names and method names are sensible
  • Methods are not too long
  • There exist some documentation

etc. etc.

but it always take some time to get the grip on new code.

You might want to run a code metric tool like NDepend or metric from inside Visual Studio to get some numbers on how complex your code is.

You could also introduce white box unit test with Pex - http://research.microsoft.com/en-us/projects/pex/, to get you started in that direction.


First of all, it is a management issue/failure that only you know this codebase, so don't worry about that. If they decide to dump you, they'll figure out their mistake in a hurry.

To answer the question... it's really difficult to answer the question without seeing the code. It really depends on your previous experience with programming, how fast you picked up C#, etc. I don't think there is much you can get from this question aside from general guidance. Having said that, if you have no to medium experience with programming -- and I'm not gonna lie here -- there is more than a small chance that the program is completely unmaintainable at 100k lines long. If you have a decent amount of programming experience under your belt, but were just unfamiliar with C#, then there's a good chance the code is reasonably well factored, but could use improvement. Maintainability may be difficult, depending on the complexity of the underlying domain model.

The most important thing -- even more important than the application code -- is that the database was designed well and all the data it contains is in good shape. I've had the experience here at this job dealing with bad code in multiple languages, bad database structures, and bad data. By far the worst is the bad data (especially client data), because without that properly organized, it may break the back of the next guy who comes along and has to either modify the database structure or the application code to add something new. We actually had to give up on a set of features for one of our applications because the existing client data is in such an inconsistent state. Application code can be replaced/refactored easily, while client data is the most difficult to replace.


From experience, it takes a long time to get used to a code base, especially if it was worked on by a single person who was learning on the job.

Yes, it may be expensive for your employer to do this in the short term, but having more than one person know the codebase and work de-risks you as a single point of failure.

Businesses have other priorities than simple cost.


My first question is usually, "did you write ANY unit tests???". If you haven't, and you care about maintenance and improvements based on the existing code, you really need to have unit tests. At the very least, they provide some kind of documentation on how to use your classes and methods. In addition, if you have tests in place, then when people refactor / untangle your spaghetti, at least they will know that the basic functionality is intact.


The eternal administrative versus technical "war", if you pass me the expression.

Getting into someone else's code is one thing. That is generally fairly doable but one may encounter some difficulties. But that is not the major difficulty. I think the administration may be aware of that anyhow.

The major difficulty accoring to me is the company's domain of activities. When a person comes in a company, the biggest challenge is to get to know the systems, the domain related issues, the network infrastructure and so on. That, you have already. It would be foolish, according to me, to "exchange" your knowledge for another new recruit, no matter the experience this new recruit may have.

However, no one is, or should do to be, irreplaceable. Developers who thought so by trying to keep all the hints for themselves about their work have lost much more than the company replacing them. On the contrary, if you're about to be undercut, or doubt so, provide the most handy practical help possible. This will demonstrate that you're over all that. I do not say that it will be easy though. But this is the best you can do on a professional matter. Then, you're going to be viewed as a greater value professional buddy.

That said, you should not resist as you will for sure find something somewhere else. It is pretty unsecurizable as a situation, but keep in mind that before each new challenge comes this kind of instability. You need to get out of your comfort zone in order to advance and progress toward new a more important challenge. You never know where it will conduct you. One thing is for sure, you will always get what you're working for, one way or another, just keep striving.

I do wish you the best of success with this situation.


After reading your employee-company and company-company deal, I have some things to add. As being the president of my own company myself, I can say that if you're working into the customer's office, this is generally owned by the customer as he has paid you to write his system according to his requirements, etc. I understand your concern about that, but I wouldn't bother with such details. Coding is coding, and that is what you seem to do very well. Even if they wanted to be the owner of this source code, you will always be the one who created it and this gives you a few steps forward compared to any other one who will step into it. Anyway, they cannot lobotomize you, so you will be able to produce a code that does what it already does for them, and even improve it as you've grown more and more efficient and fluent with the technologies you used during the development process. This, they can't take it from you.

Furthermore, I would also like to add that if you have done this for them, developing the softwares, administrating the network infrastructure, etc. then you should be able to provide the same to any other customers you can find. The most important thing, is not to lose your customer in somehow. Stay in good terms with him. Advise them wisely and be honest with them. One way or another, you'll perhaps be the one to wait for them after a period of time, after they have experimented what they thought they should do, then conclude that they should have done what you told them at the first place. Then, you will gain even more credit to their eyes, and to others' that may even bring you other customers.


Here is the link to Eric Lippert's blog and the subject I want you to see, if you don't mind.
Attracting Talent, summarized Please scroll down until you can read: "The last point I want to talk about in a bit more depth." That is realted to what you said about not being "superb"... The whole article is quite interesting either. =)


Wrong question. From your situation, what you mean to ask is "am I irreplaceable?" And, sometimes unfortunately, the answer is always "no."


I would kind of agree with you on some points, I would be very slow to agree a deal for maintaining someone else's code base without having a very good look at the code first.

I've had a few occasions to take over code work from both good and bad developers and taking over from a bad developer (or in your case one not necessarily familiar with best practices) is a soul-destroying experience. In a lot of cases I've just looked at a chunk of code, tried to figure out its purpose and completely re-written it.


Well it is quite difficult for another team of developers to learn your code without your cooperation. There are tools that try to assist but at the end of the day a human being has to understand how 100K lines of code work together and I am sure that even for you that is a difficult task.

Most likely the other team will choose to rewrite the entire application from scratch.


I think the worst way you could deal with it is telling your bosses:

I'm not giving you any technical documentation and I accidentally deleted all the comments bwa-ha-haaa!! SMOKE POOF

It sucks not knowing if you're going to be undercut but you've done the right thing. As long as your bosses understand how complex a system is, they'll assume it's generic enough for anybody to jump in.

And you should be competitive but you shouldn't starve yourself just to stay on the project. Prove you deliver value. If you can't do that, start talking people about a severance package including training your replacement. There's always another project out there somewhere and you could profit in the short term as well.


Whether or not you are more expensive to keep or to replace is not your problem, it is the managements problem. Your problems are a) Am I happy working in this environment? b) Am I doing the type of work I enjoy, am good at, and am I adequately paid for it?, and perhaps, c) am I conducting myself in a professional manner?

I had a company owner who never fired people, he harassed them with incredibly unprofessional behavior until they finally quit. Eventually I resigned, giving a full 30 days notice (unlike most of the many others who simply ran screaming out the door). I used that time to clean up loose ends, make sure that others knew where to find my carefully written documentation, and that the transition would be as smooth as possible for whomever had to pick up where I left off. My biggest mistake was lingering on in the hope that things would improve, and failing to recognize the writing on the wall and cut my losses by leaving sooner.

I felt that I acted honorably and professionally and could move on to my next employer, whomever that was going to be, feeling good about myself. There will always be a "next employer", and they are unlikely to want to hire someone who speaks negatively, much less acted unhelpfully (in their view) towards a previous employer.

It sounds to me like you should be heading for the exit rather than trying convince someone to keep you in a position that you yourself find untenable.

Good Luck.


Difficult one. I'd imagine that it would likely take a few months to get up to speed on it in the absence of any documentation.

However from the companies point of view if this is a critical application they need to ensure that you are not indispensable.