Notice that the “Please do it like this so I am sure I can maintain it” is actually a very good requirement – most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said “Hey, it works and I’m gone, bye” leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say – as Heinzi hinted in the comments – that “this is a quick prototype written in C# which happens to look very much like C – shall we make it production ready, or reimplement it in ANSI C like you asked”, and then take the discussion now. Having actual source to see, is much better than “Hey, shouldn’t we write our next application in Haskell because its faster”.

In other words – you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review – this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

Your boss would seem to be your customer in this case, and his primary requirement is that he be able to maintain the application when you move on. This seems quite reasonable.

So, the choice is to do what he asks, or demonstrate that you can complete development AND teach him how to maintain a C# application within the time constraints and at a lower cost. If you cannot do that, you are not meeting the requirements of the project.

You haven’t given a lot of info but I think C is absolutely the right choice – I work as an Engineer in an industrial plant and most (if not all) of our code is written in C. If you need to get measurements from a device (I’m assuming a flow meter or thermocouple or similar here) and display it in near to realtime C is an excellent choice.

It’s fast, portable (I’ve never written in C# but I don’t think it works without a particular version of the framework installed and it is usually only windows based).

By all means you could use another language to do the GUI. But you could save yourself the effort and just use a pre-existing trending package (there are some good opensource ones available).

To summarize I’d say for the underlying interfacing with hardware part C is a fine choice.

Oh dear. This is a real-time application? Controlling equipment in real time? Gathering data in real-time? Using a language with a garbage collector? Oh dear.

While I agree that you can probably do the app in a more modern language in less time, that’s probably not the major criterion. EASE OF YOUR PROGRAMMING IS PROBABLY MUCH LESS IMPORTANT THAN THE OTHER CRITERIA, such as the ones your boss laid down, AND response time, and deterministic behavior.

I would have suggested you do a prototype in C# or Python, just to test out the main functionality and UI. THEN test the heck out of it, measuring actual latencies and response times, when the app gets hit with a lot of data, over many days of continuous running. Odds are, the app could end up being too slow or fall behind at random times, when VM or the garbage collector kicks in.

I suggest you present what you’ve done as a PROTOTYPE.

Coding in C isn’t that hard. If you’re not up to it, say so. There’s plenty of us up for the challenge. ( I’ve been doing real-time C coding for, argh, decades now ).

Well, the first thing to do is to go to your boss and fess up. You’ve disregarded his clear request, and worse have been doing so for months. I don’t know how much time you’ve got into this, but assuming that it’s most of the time allocated for getting the project done, you have to face up to the fact that you may soon be looking for a new job.

The sooner you deal with this the better.

Secondly, I don’t think you can convince him that ANSI C is inadequate, what you need to do is convince him of several other things (1) that c# is adequate, (2) he can easily learn to maintain c#, (3) that you were inadquate to writing it in C. Assuming that you still have a job and a part to play with this project, I would concentrate on 2, emphasising the similarities between c and c#.

Quotes in response to comments…

A few months ago, we started developing an app […]
After a few days, I scrapped the entire thing and started anew using C#

has mandated that we develop this application in ANSI C. The rationale is that he is the only one that will be around the entire time, and therefore he must be able to understand what we are doing.

This is a pretty reasonable requirement.

He also ruled that we should use no abstract data types;

This doesn’t make sense. Now it is starting to smell a bit suspicious, because this is a program design requirement and not a language requirement. If the code should be easy to maintain, implementing ADTs or using well-tested, pre-existing ones should be a priority.

he even gave us a list with the name of the global variables (sigh) he wants us to use.

Ok, so now it stinks. Now we can tell that your boss has limited experience not just from various programming languages, but from programming in general. A skilled veteran programmer, no matter language preference, would never make such a statement. (The only exception that I can think of is if most of the code is intended to run on a fairly small embedded system, and therefore that all necessary working memory for the code was expected to be pre-allocated. The idea that the same code is expected to have a screen level UI argues against strongly that being the case, however).

I’m guessing that your boss has never been involved in large scale, mission critical software projects, but he has more likely been floating around in various low-quality ones.

So this has nothing to do with the programming language C. You can easily write equally icky programs in C# as well. It is a very common mistake to believe that good program design depends on the language. That is simply not true!

C# certainly has prettier, cleaner and less obscure syntax than C. It has plenty of program design support, since it has far more OO-related keywords than C. But apart from that, it does not tell you how to write your programs. If you believe that everything written in C is awful by default and everything written in C# is heaven by default, I bet you are currently writing rather awful C# programs without realizing it.

What I would suggest is that you make an abstract, language-independent, but detailed program design before anything else. Use the normal, object-oriented approach. What objects are there and how do they communicate between each other, what are the dependencies needed etc etc. When you have given the program design enough thought and gotten it down on paper, it shouldn’t matter much to you nor to your boss which language you chose to implement it in.

The first issue you have to address is an emotional, irrational one. The IT industry is one in constant change and, although there are places for everything, refusing to improve or embrace change is a problem.

Why is your boss clinging to ANSI C? If that is the only language he or she knows then maybe it is time for a change but a rational argument may be insufficient. Will your boss feel undervalued or possibly fired if forced to work in an unfamiliar language? Emphasize the experience that he has and other benefits he brings.

If you do not solve this problem, all the rational arguments you can bring will be wasted. As a subordinate, you may not be the one that can have this discussion with him. Perhaps broach this subject to one of the other managers, if there are any.

Also consider it from your perspective. Why do you want to use C#? How much of this is the desire to use something new and cool? Be honest with yourself. If you recognise this, it will help you argue more effectively.

The second issue is one of risk and cost. Writing software is expensive and the choice of language is a major factor in that. Consider:

1. How long will it take to write in C# versus C? With easier object orientation and better garbage collection, C# may be easier. However, if the application uses lots of unmanaged API calls, C may be easier.
2. If you use C#, do you need to purchase additional tools? It sounds like you already use Visual Studio but do you need additional tools for localization, code review and analysis, debugging and so on?
3. How easy is it to maintain? If you find a bug, how quickly can it be fixed. C# can reduce this object orientation. Automatic garbage collection also avoids most memory leak and pointer issues.
4. How easy is it to support? If you have support staff, they may know how to read a crash dump but do they know how to use windbg with SOS? Do the target machines already have an appropriate version of the .Net framework installed?
5. Consider staffing. How many people know C versus C#? If either or both of you left the organization, how easy would it be to replace you? Are C developers cheaper or more expensive than C# developers?

I could go on but the point is to stop arguing on the technical merits of the languages alone. Technical merits are things only you and your boss understand. If you start talking business impact, you pull in a much wider group of people and make a far more convincing argument.

Maybe C is a better choice. C# is no automatically better for all situations. Maybe you do this project using C but do a C# proof of concept for the next one. Remember you can lose the battle but still win the war, too.

Maybe another argument: It’s probably very hard to find computer science students who have enough experience to write C code without making mistakes. ANSI C is not the first thing people learn today.

Now all computer science students will kill me.

You have completely failed to convince us that ANSI C was inadequate. C is an excellent language that seems adapted for the kind of tasks you have described. With the short description of the task (except the language requirement), I would also recommend C (or maybe go).

I think the problem is that you were programming in C with your mind thinking in C#. I have a similar problem when I switch from Perl to C or java. You must learn to adapt to the language, and not learn to translate from your way of thinking toward the language of the day.

The problem is not your boss or the C language, the problem is to open your mind toward different ways of thinking. Changing programming language is something that will benefit you.

First off, you need to tell your boss it’s in a different language, now. He’ll be (understandably) angry if you bring back something purposefully against the requirements with no notice.

Now, the best way to explain these things to boss/managers is to put it in terms of time and money. Estimate how much time such a project would take in ANSI C, and then estimate how much time it would take in something higher level such as C#. Note I said higher level, not modern. This may help to smooth things over as well. I mean, you wouldn’t tackle painting a room with just a tiny paint brush, you’d use rollers and other things that make each stroke(line of code) cover more area of the project. Also, if you or one of your team members do not know C, or comfortable making a large project in C, this eats into the time issue even more because they’ll be having to get up to speed.

It also sounds like your boss is trying to micromanage. I’m sure one of the other answers will try to explain how to get your boss to do that less

The supervisor aversion to ADTs was addressed elsewhere, as was the dev’s seeming unawareness of GC costs, so I’ll focus on “threads”.

Perhaps rather than thinking in terms of .NET (or JVM, if so indoctrinated) threading, what you may want is multiple processes, using some inter-process communication (IPC) mechanism to communicate between them. E.g – windows messages, shared memory, memory mapped file buffer, named pipe, whatever. Dedicate small processes to interacting with a device or aspect of the device and checking the IPC to communicate updates and acknowledge requests, and have a somewhat larger process to maintain the GUI and communicate with the equipment “monitors” using whatever IPC you select.