Fog Creek Software
Discussion Board




How would you find a really good MFC programmer?

Our company is looking for a really good MFC programmer.  Not the heir to Blaszczak, or anything, just someone that knows it really, really well.  We're going through recruiters now, and getting tons of former web and wireless developers.  Talented people, I'm sure, but not what we need.

I would have thought with prosperity being just around the corner and all, MFC people would be hanging from the trees.  Did *everyone* go out and learn Javascript, or what?  Why is this so difficult?

Anyway, mostly I just want to complain, but if anyone has any brilliant ideas for how to (secretly - the home office would *freak* if they found out) find a great MFC programmer, lemme have it.

Or, if you just want to complain about recruiters, I'd love to see that too!

Mehndi (it's just a word, I'm a 'mericun)
Thursday, June 26, 2003

My experience has been that the better you know MFC, the less you want to use it. So those really good people you want aren't applying because they don't want yet another MFC job.

Chris Tavares
Thursday, June 26, 2003

Honestly, I think any great programmer can master MFC very quickly. So I would concentrate on finding great programmers who can learn new things quickly, instead of finding someone who has a particular skill. Because if a few years from now you need to do something else, a great programmer can always adapt to that, whereas someone who strictly is MFC may have trouble.

vince
Thursday, June 26, 2003

I'm not a good MFC programmer, but I have used it to produce a couple of small applications (see http://freespace.virgin.net/martin.mamo/ffun.html - one of them can even be run directly from a webpage as I wrapped it as an ActiveX control).

I'm of the opinion companies should really look for good programmers that can learn new things.

You can learn enough MFC to be useful within a few weeks (I did!) assuming of course you know something about user interface programming in general and of course C++.

Savage Planet
Thursday, June 26, 2003

"The better you know MFC, the less you want to use it."

Hilarious, and true! I'm an MFC refugee, too. ;)

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, June 26, 2003

Well really good MFC developers generally also have solid win32 Skills to back them up!  There's no quick way around this simple fact. 

Recruiters are generally not well equiped to properly assess the level of skills needed to be considered competent within the MFC/Win32 development domain.  In effect you're wasting your time with recruiters, once you go beyond scripting languages.

One potential recommendation would be to require that the  candidates pool be brainbench certified in the respective technology areas, before they can be submitted.


If you'd like more details send me a private email.

Unicode Guy
Thursday, June 26, 2003

Vince said: "Honestly, I think any great programmer can master MFC very quickly."

We must be using different meanings for the word "master".  No one can "master" MFC "very quickly".  The idea that one could explains a lot of the code I've seen.

The person we're looking for has years of MFC experience; someone, who, for example, can do MI *correctly* with MFC (any idiot can do it incorrectly).

I wonder what "brainbench certification" is?  Well, I'll google it - probably I'll be able to "master it very quickly"!    ;)

Mehndi (it's just a word, I'm a 'mericun)
Thursday, June 26, 2003

Do you already have a system built on MFC?  Otherwise, for new development why would you want to develop with MFC?  It is a clunky, convoluted, and outdated API, and almost anybody smart enough to master it would also be smart enough to get away from it by now.

T. Norman
Thursday, June 26, 2003

Chris Tavares has hit it. I consider MFC to be the non-optimal solution, selected by people new to Windows programming. Win32 yes, MFC no.

It's actually an interesting issue. Sometimes people need deep expertise but have only a narrow view of the development environment, so they specify they want an "expert in MFC" or an "expert in Director" or something, when that expertise will be found under a different designation.

For example, does the original poster have some particular technical task they want performed?

.
Thursday, June 26, 2003

Many people seem to think MFC is Very Bad, but no one has given the alternative.  I'm not a Windows UI guy, so I don't know.  So what is the alternative to MFC (ie, what other tech lets you do the same thing as MFC)?

Crimson
Thursday, June 26, 2003

Are you guys kidding?  Yeah, Win32 is great if you want to spend 10x as long developing an application as you would with MFC. 

With the exception of the full blown DocView stuff, MFC is not much more than a thin wrapper on top of Win32.  I don't see how anyone with a little experience with both could possibly chose Win32 over MFC given that they aren't that much different, other than MFC takes care of many of the tedious details for you.  There is nothing you can do in Win32 that can't be done in MFC (and usually get done much quicker).  If MFC doesn't come with a prefab class to accomplish what you need, it's trivial deriving a new one. 

I'd stake my Win32 and MFC expertise up against anyone.  "The better you know MFC, the less you want to use it" should be rephrased as "The more you try to learn MFC and fail, the less you want to use it."  Don't project your inadequacies on me, please.

SomeBody
Thursday, June 26, 2003

I am starting to think if something is that hard to get working, then it probably does suck compared to an alternative.  I have never programmed MFC, but if it's easy to not be good at, then it also explains why a great many co.'s would avoid it.  It's technocentric, to some degree, to think otherwise.

Just my 2 cents, and wanted to put it out there.

Brian R.
Thursday, June 26, 2003

Respectfully disagree Brian.  This doesn't pertain specifically to MFC, but to any tech.  To really be so proficient in an API does initially have to do with how fast you can learn, but in the long run, it's the experience that counts.

After 6-7 years of doing nothing but MFC programming (well, one or two years of Java total time thrown in there concurrently), I can safely say that I've mastered it.  It may have only taken me 2-3 weeks to get up to speed, but nothing can replace the experience of dealing with the API day in day out.

It's as if I wanted to learn WTL, wxWindows, QT or another GUI API. Sure I can pick it up in 2-3 weeks, but there's no way I'll be up to the same level of familiarity without putting in the years.  That goes for anything, not just MFC.

shabob
Thursday, June 26, 2003

Since 1995, Visual Studio has tipped new Windows programmers into MFC. Most of them have never done Win32 and are scared of it.

I just find that MFC provides nothing I need. I can do everything directly in Win32. It has no dependencies, never crashes, does everything, is smaller, has zero memory leaks and resource leaks.

.
Thursday, June 26, 2003

MFC is a lousy development platform because it provides a thin, non-abstract, "leakily abstract" boundary between the API and the application. What I find in work I've done using it is that MFC's tools are low level, bare bones and primitive.


I agree with the comments stating that heavy MFC experience implies some mastery of the Win32 API. I'd be VERY surprised to run into a heavy MFC developer lacking equally deep insight into the API way of doing things. For one major thing, MFC development is still trapped in the dialog editor-resource-source code menage a trois. You have to understand dialog and other resources and what they are and what they do in order for UI development in MFC to be comprehensible at all.

MFC adds a few general things of value: it does wrap the window and window class creation mechanisms to an extent, and it has some good tools for transferring data between data variables and the UI controls.  But it's about 20% of the tool that it could and should have been for its time.

Bored Bystander
Thursday, June 26, 2003

<I'd stake my Win32 and MFC expertise up against anyone.  "The better you know MFC, the less you want to use it" should be rephrased as "The more you try to learn MFC and fail, the less you want to use it."  Don't project your inadequacies on me, please. >

Go girlfriend. I'm sure you know both very well. Probably better than me, at any rate. (I'm something of a Win32 part-timer.) But you are denying people any kind of subjective response to things they use. I have used MFC, because it provided that pretty handy doc-view thingy, which was a big advantage over my own Win32 classes and WTL, but... gods, it was ugly.

I can rant on for a while about how it was ugly, but I'll be brief and summarise the experiences of the month or two I had to use it for: the string class, the container classes, the bletcherous misuse of #define to overload new, the bletcherous use of proper overloaded new inside the library but no corresponding delete (rendering your own allocators useless without hackery -- hackery that renders them useless in a different way!), non-typed messages-to-your-doc (int+void *? Sorry, did I load my _assembler_ by mistake?), lack of control sizing or layout, everything beginning with a "C" (am I weird, or does noone else confuse their classes with other things?) and general nastiness forcing you to use class wizard and new project wizard to get anything done.

Compare and contrast with Win32 API, which in a large project is sharp stabbing pains through the eyeballs compared to MFC's dull abdominal ache, or wxWindows, which is MFCish but manages to be better-thought-out and vaguely pleasant to use, or WTL, which didn't suit my purposes (and was a bit wierd :) but managed to have MFC-style message handlers without needing the bastard class wizard. There are probably plenty more examples, but these are the ones I've used (suffered?) with C++.

I will freely admit that MFC is better than nothing, and it's already written, and lots of people know how to use it. It does not follow that it is not crap :)

P.S. I hope I didn't get (m?)any technical details wrong; I have some more complaints up my sleeve if any of the above should prove unacceptable.

Tom
Thursday, June 26, 2003

The above post is presented with apologies for some hubris that was not obvious until the message appeared all on screen at once.

Tom
Thursday, June 26, 2003

I know MFC for several years and still use it. I know the Win API pretty well having spent several years prior doing it direct. Pretty much the only areas that I've never touched is MFC's database and IIS server classes.

50% of the "problems" in code I see with MFC, are because the developer doesn't understand how the Win API works. The other 50% is because they use the Wizard to do everything. 

MFC is mostly a thin wrapper (except for the bits where they went off on a side-track, most of which aren't that great).

Advantages of MFC
- it's a thin wrapper. Doesn't hide what WinAPI is doing (much) and you can read the source
- pCombo->AddString (for example) is way better, easier to read/debug, more type-safe, than the equivalent SendMessage in WinAPI
- sub-classing controls is way easier in MFC than Win API
- you can mix MFC easily with native Win32, even for handling the same window or something
- lots of people know it, many web sites with samples/tutorials etc.
- the results can run on pretty much any Win32 machine (NT 3.51 might be a problem - not sure - but does anyone still care), and with minor work you can make it work with correct UI on each.

Disadvantages of MFC
- it's a thin wrapper.  You need to understand WinAPI to get most from it, (except in some areas it doesn't add that much)
- it's a thin wrapper. Some classes, if not used correctly, will leak.
- some classes are not so good IMHO, esp legacy classes
- lots of areas of Windows not covered at all
- the COM support is, er, confusing

S. Tanna
Friday, June 27, 2003

"What I find in work I've done using it is that MFC's tools are low level, bare bones and primitive."

And they reinvent the wheel incessantly and unnecessarily.  There's nary a design pattern to be found in the wrapper (Document/View?  What?  Why not just a standard Model/View/Controller?) and there are lots of kludgy, half-done "general purpose" classes (like CString).

Nevertheless, I tentatively agree with SomeBody and Tom on the issue of actually using the damned thing.  MFC is faster development than the Win32 itself, and with proper insulation from business logic (ie, so your core functionality isn't tainted with its nastiness), it can save a lot of time.  In some ways, MFC is a valuable exercise for many programmers--it teaches in a very illustrative way the need for abstraction.  Because God knows, MFC is the arch-enemy of portability. :)

That being said, it's really just a matter of settling.  MFC is what's supported by Visual Studio--a tool which is indisputably the best IDE for Windows development.  It has the support and the widespread entrenchment.  And from a business perspective, that often translates into a lot of encouragement from on high for its use.

Just as long as we're all aware that MFC, with its compiler-integrated macros (I'm no anti-macro Nazi, but MFC's are just egregious), is not a prime example of what well-engineered OOP should be...:)

smkr4
Friday, June 27, 2003

I doubt you need one. I develop MFC, COM and ATL these days. And let me tell you, they are the easy part of my job. MFC is good an knocking stuff up, but bad at doing anything past that, most of the time you need to build on top of it to get round bugs and limitations anyway. And therein lies the problem, MFC is badly designed, badly hacked together, macro-ridden and buggy. Worse since you normally put it together with Wizards you effectively lose half your source code anyway.

Win32 is an ugly API; MFC is whole ugly way of working.

Coming back to the point. If you're continuing developing an existing MFC app, then a competent C++ background is more important than specific MFC knowledge and Win32 knowledge is almost as useful as MFC knowledge. If you're developing a new app, don't use C++ for the UI.

Mr Jack
Friday, June 27, 2003

"The better you know MFC, the less you want to use it" should be rephrased as "The more you try to learn MFC and fail, the less you want to use it."

I don't know about that.  Our developers used MFC extensively for a number of years, but disliked the bugginess of many of the classes (IIRC, the Date functions were a particular pain).

We eventually developed our own equivalents of each of the MCF classes we use - providing us with the ability to have control over the source, the advantages of MFC without (we like to think) many of the disadvantages, and a single code base that runs on Windows and Linux.  And our code is faster...

I think it comes back to Joel's comment about the importance of determining the best tools for the job.
-----------------------
http://www.joelonsoftware.com/articles/fog0000000026.html

"When I sit down to architect a system, I have to decide which tools to use. And a good architect only uses tools that can either be trusted, or that can be fixed."
-----------------------

In our case, MFC really didn't pass that test.

Phibian
Friday, June 27, 2003

Interesting... the one thing I didn't anticipate what that the discussion would be about the merits of MFC...  I actually expected someone to ask me what city I'm in...

Anyway, yes, we have a huge existing application written in MFC - rewriting it is NOT an option.

But let me ask this, to all the people who apparently hate MFC: let's say you have a big app to write (say, half a million lines of code in all).  It makes no sense to make it a thin-client app (for reasons JoS readers will readily understand), and needs to run only on Windows.  Also, the language used needs to be fast, and needs to make it easy to do COM and low-level stuff.

Am I nuts, or can that set of requirements only be met by C++/MFC?  Am I incorrect in ruling out:

    - Java: too slow for a thick client app
    - direct Win32 programming: way too labor-intensive
    - VB: too unwieldy, and too slow

And what about C#/.NET?  Well, this app makes no sense as a web app, so what does C#/.NET offer me over C++/MFC?  I suppose I could do in VB.NET, which (I read) has theoretically the same power as C++.NET...

These are not sarcastic questions; seriously, am I just woefully underinformed, or would MFC still be way to write this app, even today?

Mehndi (it's just a word, I'm a 'mericun)
Friday, June 27, 2003

The fact that Microsoft didn't use MFC for any of their major applications speaks volumes about this issue.

19th floor
Friday, June 27, 2003

How about ATL+WTL, which gives you just about everything MFC does, but without the annoying Document/View paradigm.

Ken E
Friday, June 27, 2003

> The fact that Microsoft didn't use MFC for any of their major applications speaks volumes about this issue.

Word, PowerPoint etc. predate MFC, so you would hardly expect them to throw it away and be written with MFC!

Lots of MS apps are written in MFC. There was a list somewhere in something like the MFC FAQ. I can't remember them all, but did include WordArt, the Visual Studio GUI, chunks of IE, and quite a few others

If you don't like Doc-View in MFC, you don't have to use it. If anybody things that it is required, I think that I'd say they are letting the wizard do their thinking for them.

S. Tanna
Friday, June 27, 2003

> Am I nuts, or can that set of requirements only be met by C++/MFC?  Am I incorrect in ruling out:

I don't think you're nuts. I think MFC is a reasonable, but not perfect starting point for many apps


>    - Java: too slow for a thick client app

Too slow, and what if you want to take advantage of many native Windows features. MFC mixes very happily with WinAPI

>  - direct Win32 programming: way too labor-intensive

I consider many of the MFC classes to be a much faster and more type safe way to direct Win32 programming. It is not fundamentally different.  The other classes where they try to invent functionality not in WinAPI, you can take them or leaving them.

The big advantage of MFC for me is (a) you don't have to use it for everything (mixes win WinAPI), and (b) you don't have to follow the default way that most people set apps up - for example you aren't forced to use Doc-View or whatever, just take the bits you want.

>    - VB: too unwieldy, and too slow

It is definitely too slow for me, plus I want to go to the metal


> And what about C#/.NET

If you don't mind the huge framework requirement (what about older Windows systems?), and it's not native machine code, so it's bound to be slower


I guess there is Delphi and C++ Builder and so on too, but then you tend to end up in a specialist Ghetto.

S. Tanna
Friday, June 27, 2003

I'm a regular MFC programmer on Pocket PCs. On that platform, yes, MFC does take up memory that you might use for other things. But I think ultimately it's the right tool for our job.

We write custom vertical market data capture applications, typically with barcode scanning, typically locked down (i.e. restricting access to the Start Menu and other Pocket PC UI widgets, so the user can't switch to Solitaire). We don't currently use Document/View (although some areas would be simplified if we used CFormView-derived classes contained within a frame window rather than a stack of dialog boxes). I'm our team's library builder as well as an application designer and implementer - I'm also the hardcore debugger.

Part of the trick is to know what the wizards are going to do for you, and when to use them. The version 6 IDE (also used in eVC 3.0 and 4.0) has a major problem with extending the Wizards, mainly because it doesn't know enough about your code, or rather it knows different amounts in different places (e.g. browser information, ClassView, IntelliSense). If you don't know what the Wizard is going to do for you, it tends to end up being what the Wizard does _to_ you...

It's much easier to extend the behaviour of a control in MFC than it is using the raw API calls. We often end up doing this - the customer (or my boss) says things like 'Can we have it do _this_ when we press Enter in this field, rather than simulating the OK button'. Or we need to get a list control containing multiple lines of text for each item.

Finally, it's actually easier to teach MFC programming to someone familiar with VB than to teach them raw Win32 or, heaven forbid, ATL. Even C++ geeks struggle with ATL.

That's not to say I won't use anything else: simple launchers or setup DLLs tend to be written with the Win32 API, controls with ATL. We have a library for porting Symbol Series 3000 terminal applications, which is written using a combination of raw Win32, ATL windowing and MFC string and collection classes. I wasn't going to include MFC until I remembered that our scanner handling code relies on CString and CWnd.

CWnd isn't exactly free: MFC does maintain temporary and permanent maps of CWnds to HWNDs, which pulls in a whole load of other MFC initialisation code, which creates a great deal of other stuff. The message map implementation is table-driven and this code is in the library as well. ATL's implementation is more efficient but less intelligible.

I'd say, if you need great efficiency, use ATL with WTL. If you need reasonable efficiency and slightly faster development, use MFC. If you're writing something extremely small, use Win32. Otherwise, start looking at .NET.

Mike Dimmick
Friday, June 27, 2003

From what I remember, IE is mostly written in ATL, but I could be wrong about that.

As far as .NET goes, I'm quite glad that a lot of Windows Forms has ended up being quite configurable (e.g. Application.Run) rather than going down the old VB6 route of 'this far, but no further'.

Since the compiled code is JITted with .NET, you should only see a slight delay while the code is compiled from MSIL to the target machine language when a routine is first run. It's not quite as optimal as you might get if you'd written it in C++ and run it through that optimiser, and at present, C# and VB.NET don't attempt to produce optimal IL code, so there's often some dead code or unnecessary operations performed (e.g. reloading something just stored), but on the whole it's pretty good.

However, I don't currently have a lot of experience with .NET, since Compact Framework has only just come out.

Mike Dimmick
Friday, June 27, 2003

> From what I remember, IE is mostly written in ATL, but I could be wrong about that.

It's componentized (sp?) which is part of it's brilliant. I doubt it's all written the same way.  Delete the MFC DLL, and see if it runs :-)

S. Tanna
Friday, June 27, 2003

S. Tanna: I neither like nor dislike MFC. I consider it a useful step in the OOD evolution.

MFC dates from ~1991, I don’t think MS Office predates it by much.

As for what applications make use of MFC there is no reason to delete any dll. Use this http://www.codeguru.com/system/TaskManagerEx.html utility, in case you don’t have it already (very useful debugging tool, by the way) and check the loaded modules.

Strangely enough VS6 uses MFC, VS7 does not, nor IE6 or the Office applications. Let me know what you find.

19th floor
Friday, June 27, 2003

"Strangely enough VS6 uses MFC, VS7 does not, nor IE6 or the Office applications. Let me know what you find."

There was a post some while back indicating that VS7 (= VS.NET) is actually a relabelled Java IDE rather than a new revision of the VS6 code base. Haven't seen any confirmation for this, though.

Chris Nahr
Friday, June 27, 2003

VS.NET is the next version of the Visual J#/Interdev IDE rather than VC 6. Originally, this was supposed to be the codebase used by VC 6 and VB 6, but the VB 6 team bailed and went on with their own IDE. Then the VC 6 team did the same thing.

Chris Tavares
Friday, June 27, 2003

"MFC-style message handlers without needing the bastard class wizard. "

One way to tell if a programmer has MFC experience might be to ask him to write message handlers without using the class wizzard.

Once you use and understand MFC you will understand what the class wizzard does, and you can probably type the boilerplate code almost as quickly as calling up the Wizard and fillling in the blanks.

If you haven't tried MFC 7.0, it's got a good start on some excellent HTML GUI classes. They are about 85% done, but very useable as is and of course you can expand them.

It's great to be able to get an artys fartsy type to describe the GUI with HTML and then use good 'ole MFC to do the behind the scenes work.

Jim Howard
Friday, June 27, 2003

really good MFC programmer

well, yeah, that's me
(among other things as well)

Michael Moser
Saturday, June 28, 2003

You know, I'm reading these posts and what strikes me is that many posters have no solid foundation for saying that MFC sucks, and why, or that Java sucks, and why.

Both are great and suck at the same time.

Both are great because you can use them to produce real-world applications. Both suck because they have blemishes and flaws which perhaps could have been recognized and prevented.

MFC is good in some respects, and Java is good in some respects. MFC might not be good in the same things that Java is. Both can be used to produce real world applications, but not necessarily the same types of applications.

MFC has the advantage of being a mature and well understood technology, running on top of a mature and well understood platform (Win32).

Notice that I don't claim that either MFC or Win32 is perfect. If you have any significant experience in programming for them, you know that. But you can use them to successfully produce real world applications. Besides, I suspect that you could make the same claims about X/Motif and whatever the Macintosh equivalent is called. Imperfect, occasionally deeply flawed, but workable, and with experience, capable of handling complex, real-world applications.

What about Java. Its approaching the same real-world problems from a different perspective. If you're looking for a modern replacement for MFC/Win32, you  may be in for a big disappointment. But, if you're looking for a technology for producing platform independent, web-based apps, perhaps Java is for you.

If your core business is directed toward supporting clients on Windows, perhaps MFC is better, and maybe .NET better yet. Maybe even Visual BASIC (gasp!). Probably using Java and SWING in these circumstances will result in a less than optimal solution -- its doable, but why?

If you have an immediate and direct need to be concerned about multi-platform issues, then again you may need to put up with the blemishes and imperfections of Java and SWING.

The debate should be based on what is required in the real world. Let that dictate the choice, rather than time-wasting arguments over the theoretical merits of one over the other.

If you have lots of legacy code that could potentially be reused, and its in MFC, where's the question?

If you are starting from scratch, thats a different matter.

Sorry for the rant, but I'm relaxing after a continuous one month push to get a combined MFC and Java app suite out the door.

AnMFCAndJavaProgrammer
Sunday, June 29, 2003

MFC Sucks - No such thing as a "good" MFC programmer.

C++ Sucks
Monday, July 26, 2004

"Strangely enough VS6 uses MFC, VS7 does not, nor IE6 or the Office applications. Let me know what you find."

Fire up the VS6 IDE and measure its workingset. Fire up the VS7 IDE and check out how much memory its using. Perform the same activity again, this time comparing how long it takes between starting the IDE and the moment you could do work -- click your first button or drop down your first menu, for example.

Was the decision to not use MFC the right one?

Several Office XP components use MFC, by the way.

Omar
Thursday, August 26, 2004

*  Recent Topics

*  Fog Creek Home