Fog Creek Software
Discussion Board




The real enemy of programmer productivity

The topic on 80% programmers are useless really got me thinking about why. I think a big part of it is just management doesn't know how to select who is productive and in many cases, cannot even create an environment where anyone can be productive, but I think another huge issue with productivity is the ridiculous technology as a fashion statement strategy that every company not even just tech companies have adopted!

I think that no programmer who starts working today can ever really hit his stride, because every few years he will be forced to change languages, now the zealots with computer science degree's will chime in at this point and say, all that matters are concepts not languages or trivia and to a certain extent that is true (although you  don't need a degree to learn concepts), but most decent programmers can pick up pretty much any 4gl and be somewhat productive within 3-5 days (at least to the point where they can maintain existing code), but the problem is that its not in the concepts that some of the biggest obstacles to productivity lie...

As some of you guys know I quit the software development biz to start an insurance agency, and this is a field where a)no software is open source, and the amount of paperwork  is simply overwhelming, so one of the things I do is build simple programs to help me automate the more mundane tasks- requesting inspections, data entry...

One such particular program was a tool that let me pull data from an email requesting a quote, and enter it in my quoting program ( a program I can't modify directly) so I am using a gui automation tool to enter the data manually, now the language of this tool is a 4gl that I haven't used in a while, but was fairly straight forward and within 2 weekend days it was working 95 percent except for one liitle bug, it was always inputing 49 as the square footage of a house, no matter what I put into the database, or how I tweaked and double checked the query.
I spent a day going over the code until I was nearly insane with frustration, and then after a short break it finally hit me

this language binds a variable to a column in the resultset and the fetch next command (method/function) whatever simply puts the next rows value into the variable.

Well as it turns out the language is very strongly typed (about on the level of java)  ... but it DOES NOT PERFORM TYPE CHECKING ON VALUES IT GETS FROM RESULTSETS, and I had forgotten that I changed the type of one of the DB fields. Now I had a respectable knowledge of this 4gl, but I had not worked with it enough to master all its idiosynchrosies, and that made me at least 33% (3 days versus two) less productive than a programmer of the same caliber as me who would have been a master, now I submit that that extra 33% is what lowers a ton of good programmers to decent or bad! And I also submit that if we simply stuck with the languages/tools/Standards we already had, we would get a lot more productivity out of the current work force

the artist formerly known as prince
Friday, December 05, 2003

Wow, I thought *I* was verbose.

Sam Livingston-Gray
Saturday, December 06, 2003

While verbose, I agree with you, Mr. "Ankh Symbol". The churn in programming technologies effectively makes us "stupid" in being able to deliver solutions when we allow ourselves to chase the new language or tech being pushed.

I've stayed with Delphi for seven years because the language platform has been exceptionally stable and backward-compatible, and the programming model has been largely invariant since the Windows 3.1 version of Delphi. That allows me to produce faster, better and quicker.

The fact that C# was architected by the guy who invented the Delphi programming model, and that C# looks almost like Delphi says exactly two things: one, most programmers and most of the "IT media" are stupid and lack wisdom about the history of, and the antecedents to the commercially popular offerings of today; and, that nothing is really new.

The only reason I consider other languages is because either another language does something that Delphi can't, or Delphi simply isn't available on the OS I want to use.

Bored Bystander
Saturday, December 06, 2003

By the way, your thread title belies the point of your rant. I thought it would contain some commentary on construction of a better programmer work environment, or some commentary on the mental blocks we developers encounter in real life.

However, it was still a good point.

Bored Bystander
Saturday, December 06, 2003

Dear Bored,
                  The fact that Delphi remained stable for seven years since the time of Windows 3.1 often shows in the UI of the apps it makes :)

Stephen Jones
Saturday, December 06, 2003

Ha... ha. Ahem, Stephen, I've done Visual C++, Borland C++, Visual Basic, and others. Whatever I can do and whatever controls I can use in any MS tool, I can do and use in Delphi. I consider your comment typical of the bias in our industry.

My client sells his Delphi based application (for which I developed the core UI) to a customer base of 20,000 workstations.

If you think you observe a deficiency in Delphi apps, blame the poor market penetration - IE, the fact that there are not enough shops selling Delphi apps to allow a fair statistical sampling to take place, and the fact that shrink wrap shops don't often publicize their tool set.

Bored Bystander
Saturday, December 06, 2003

Fire and Motion baby, Fire and Motion.

Notice that Microsoft's top developers still write everything in C and C++ while the 'unproductive' ones all are racing after the next big thing, be it VB, new and improved VB, dot-net, whatever. Meanwhile the productive programmers stay with the same language year after year and kick everyone else's rears while they wondered what happened.

Yep, great point. Fire and Motion.

Dennis Atkins
Saturday, December 06, 2003

Anybody who thinks Delphi's UI capabilities are sub-standard just needs to look at FeedDemon. That's one sweet UI, and it's all Delphi.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, December 06, 2003

"Notice that Microsoft's top developers still write everything in C and C++ while the 'unproductive' ones all are racing after the next big thing, be it VB, new and improved VB, dot-net, whatever."

Hm, I don't know, Microsoft doesn't exactly target VB as a "core tool development platform."  To me this is not a "fire and motion" issue, so much as an "ownership" issue.

In the sense that, really smart companies develop their core tools from scratch, so they own them from the ground up.  While this is more expensive, they avoid the churn the original poster is complaining about, because they own and control every inch of their technology.

Microsoft is obviously the king of this.  Whereas many firms are outsourcing everything (and I mean that in the technology as well as the labor sense).

There probably is an element of fire and motion, but from the OP perspective, it doesn't sound like he's adopting the new technology just to adopt it.  He just needs the "high level" functionality, and he can't afford to build it from the ground up.

So yea, it sucks that standards and good practices aren't followed in all tools we use.  What really sucks more is that we have to use third-party tools. :)

But in a free-for-all industry like this, how can we ever assure standards like, say, type safety make it into small vertical market apps?

(that's not a rhetorical question)

it_ranter
Saturday, December 06, 2003

> Notice that Microsoft's top developers still write
> everything in C and C++ while the 'unproductive'
> ones all are racing after the next big thing,

I'd be fascinated to know where you learned this "fact".  What data supports it?

I do not know whether I am one of the "top" developers or not, but I do know that I write lots of code in both C++ and C#, and that I produce much higher quality C# code, much faster. 

I personally wouldn't care to speak to the experiences of the other thousands of developers at Microsoft, but perhaps you know more about them than I do?

Eric Lippert
Saturday, December 06, 2003

If you have the inside information, Eric, then tell us otherwise -- Of Microsoft's commercial software offerings, how many are written in any language other than C/C++?  I can't answer this question myself, but I would guess that the percentage is very close to 100% (if not actually 100%). Of course the evangelists will proclaim that the next version of xyz is going to be 100% managed code, blah blah blah, but let's just say that such proclamations are easier said than done.

Dennis Forbes
Saturday, December 06, 2003

Eric,

You know that the top guys where you are are working on the most critical things, like the kernel, the file system, the graphics subsystem, the compilers -- the back bone.

This stuff is not written in C#. Or have things changed?

Dennis Atkins
Saturday, December 06, 2003

Whooops....in the above I intended to say that the number of commercial Microsoft apps written in anything other than C/C++ was close to 0%, or 0%, and by corollary that the number of commercial Microsoft apps written in C/C++ is close to 100%, or 100%. Phew.

:-)

Dennis Forbes
Saturday, December 06, 2003

>The fact that Delphi remained stable for seven years
>since the time of Windows 3.1 often shows in the UI
>of the apps it makes

Stephen, you're talking out of your ass.

Matt Foley
Sunday, December 07, 2003

> Stephen, you're talking out of your ass.

That's a bit harsh.  Sounds like you're upset because no-one likes those command buttons with the red cross & green tick on them any more.

Well, except Borland.  (or whatever they're known as)

Now that was a short-lived GUI fad.  Now about CoolBars...

AJS
Sunday, December 07, 2003

Time moves slowly.

True, there are probably virtually no commercial applications from Microsoft written in C#. But is that because C# sucks? Or is it because these apps exist from a time before C#?

Ask this question a few years from now, when product lifecycles for new products will have given them the opportunity for using .NET.

To me, the "top" people at Microsoft ARE the ones who are working on and in .NET. I wouldn't consider some Excel code maintainer the top of the food tree of Microsoft engineers.

As for not doing anything critical in .NET, the next version of the Windows shell is written in .NET. *shrug* Now you can argue whether that's critical enough to satisfy your own self test, but it sure is telling enough to me.

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, December 07, 2003

"But is that because C# sucks? Or is it because these apps exist from a time before C#?"

Who said C# sucks? I most certainly didn't, but the reality is that Microsoft made itself a half-a-trillion dollar empire almost entire using C/C++ as their foundation.

"I wouldn't consider some Excel code maintainer the top of the food tree of Microsoft engineers."

You have absolutely got to be kidding. The .NET folks are now filling the role that the VB branch used to--basically push out whatever you want, because the sheep-like masses will eat it up and call it good regardless. I'm not saying that this means that .NET isn't worthwhile (as I've stated many times -- it is a fantastic environment). The office "code maintainers" have to develop enough every couple of years to basically support a large part of the organization (as the office group is one of the largest income generators).

Dennis Forbes
Sunday, December 07, 2003

--"  Sounds like you're upset because no-one likes those command buttons with the red cross & green tick on them any more."---

Yep, they were the first thing that sprang to mind. And I did put a smily at the end of the comment.

Stephen Jones
Sunday, December 07, 2003

Dennis, the fact that C/C++ was used for most applications in the past does not tell you anything about whether or not that will hold true for the future.

Folks at Microsoft, like most smart developers, will tend to use the best tool for the job. C/C++ is not always the best tool.

Heck, the team I worked on until just recently shipped a product in the spring that had major portions written in C#, and that from a group at Microsoft that is about as traditionally C/C++ focused as you can get...

Mike Treit
Sunday, December 07, 2003

"Dennis, the fact that C/C++ was used for most applications in the past does not tell you anything about whether or not that will hold true for the future."

Indeed, this is very true. However I would say that time will tell, and hand waving and prophecies right now mean very little -- A few years back we were promised a plethora of amazing software products built entirely in Java -- we all know how that went.

It is fascinating counting how many commercial Microsoft products were built using Visual Basic -- I mean this was the dogfood that everyone else was convinced was the true way to salvation and amazing productivity.

Dennis Forbes
Sunday, December 07, 2003

"The fact that Delphi remained stable for seven years since the time of Windows 3.1 often shows in the UI of the apps it makes"


Bullshit. Three words: Dev-C++, FeedDemon, Delphi 7 (all made in Delphi).  And if that technically surpasses the aforementioned 3 words please hold your breath while I make an effort to give a fuck.

TJ
Sunday, December 07, 2003

"It is fascinating counting how many commercial Microsoft products were built using Visual Basic -- I mean this was the dogfood that everyone else was convinced was the true way to salvation and amazing productivity."

I dare say that there are plenty of internal apps at Microsoft written in VB, much like the rest of the world.

Shrink wrap software is a pretty small section of the programming landscape compared to internal apps, so is it any wonder Microsoft market tools towards that (presumably more profitable) section?

Sum Dum Gai
Monday, December 08, 2003

"presumably more profitable"

So the biggest software company in the world makes more profit from doing internal apps for people than from selling shrink wrap software?

Dennis Atkins
Tuesday, December 09, 2003

"a pretty small section of the programming landscape"

Honestly, I am extremely skeptical of this. It seems outlandish to me actually. Do you have any support for this? It seems to me that more than holf, possibly much more than half of profit made on software is shrink wrap. Shit, the damn games industry made more profit than the entire Hollywood industry a few years back (don't know if this is still true, but I assume it is).

Really, the internal one-off apps market compared to shrink wrap is absolutely NOTHING. It's so small that it doesn't even show up on the land scape. Programers working on internal apps are a tiny tiny miniscule part of what is going on, though I do believe that the folks working on that stuff think they are the be all end all of the universe.

Dennis Atkins
Tuesday, December 09, 2003

Dennis, it depends on what you are talking about. I think you are confusing the poster's parenthesized comment with the rest of his post. Obviously shrink wrap (Microsoft) is more profitable than writing internal apps, which is usually a cost center.

However, there are internal application programmers at nearly every mid to large organization, from non-profit charities, to insurance companies, hospitals, banks, insurance companies, phone companies, biotech companies, universities, government, etc. I think what the poster meant was that the number of programmers working on shrink wrap products is a small percentage of programmers in general, who are often writing and maintaining internal systems.

_
Thursday, December 11, 2003

*  Recent Topics

*  Fog Creek Home