Social Enterprise

Justin's meta post


I like numbers, and I have always enjoyed trying to quantify subjective things. Throughout the past year, it's been interesting for me to attempt to quantify reader reaction to this blog. I try to write about things at the intersection of my personal interests, the interests of readers, and the stated purpose of this space (Programming and Development). Here's my take on what I am seeing and how it can be analyzed.

In terms of methodology, my measures are somewhat imperfect. I have incoming links from other blogs showing third-party interest in the posts; I have the “thumbs up” voting system numbers; and there is the volume of reader feedback. Reader feedback can also be loosely divided into three portions: threads ignited by the original piece but barely related; threads directly about the topic the original poster discusses; and simple commentary like kudos, flames, typo notices, and so on. I am also somewhat taking into account blog posts by other TechRepublic contributors to the Programming and Development space, but I'm primarily looking at my own blog posts.

The topics that seems to receive the most back links overlays quite nicely with the pieces that tend to get a medium-to-high number of “thumbs up” votes and that is the how-to pieces and reviews, which are primarily written by Tony Patton and Peter Mikhalenko. Good job, guys! It is pretty clear that these pieces are much appreciated by readers.

It's interesting that the opinion pieces written by me or Rex Baldazo usually only get a few links back and a few “thumbs up” votes. However, when we do get those votes, we get a lot. The trend seems to be that our highest voted pieces outpoll the highest voted “fact” items, but the “fact” items nearly always outpoll “opinion.”

In terms of reader feedback, my pieces definitely tend to spark the most discussion. The “fact” items tend to generate extraordinarily little feedback. Gladly, I can only recall a few times in which near brawls erupted in the forums, and even heated disagreement rarely became uncivil. Feedback on the “opinion” pieces, naturally, strayed quite a bit more from the original item than the “fact” pieces. Only in very rare cases did we get any “minor commentary” posts (kudos, flames, typo notices), and they were almost always just typo issues. Thanks for not flaming us! I also took a look at who seems to be making up the “frequent commenters” and the “infrequent” or “one-time” commenters.

From this information, I have drawn the following conclusions:

  • Readers use the “thumbs up” votes quite specifically to indicate a post is useful. This is in stark contrast to reader behavior in most other blogs I have seen. In most blogs, a positive vote means “I agree”, and a negative vote means “I disagree.” Readers will not vote for a piece in this area unless it truly is useful.
  • “Thought provoking” or “interesting” is not sufficient to get a vote. Lack of votes does not mean something is bad or that the readers do not like it -- it just means that they probably will not print it and stick it on their desk to refer to later.
  • The average person who comments back is typically a high to intermediate or expert programmer or at that same level in some segment of IT. You are also mature, experienced users of forums, and most of you can remember BBSs, judging by the etiquette displayed. I am not going to name any names (you know who you are, and I’m sure to forget someone), but overall I see two groups of commenters: “old hands” and “eager newcomers.”
  • A surprisingly high number of you seem to have multiple decades in the industry.
  • Some topics receive really high volumes of "white noise" commentary; these are nearly exclusively “religious” topics. At this point, posting something on them feels almost like trolling. These topics include:
  • -- Language choice* (caveat below)

    -- Programming style such as indentation, notation, use of comments, etc.

    -- Stupid bosses and coworkers

    * Language-related items can be quite interesting and non-troll-esque if handled properly. The author of the original piece has to set the tone by basing conclusions on person experience and fact, and show both of them. When written like this, the conversation is great. I can bring up problems with OO, Java, VB.NET, Perl, etc. without flame wars, and the readers seem to like reading (and writing back!) about it quite a bit when done like this. When done wrong, it is just trolling.

  • The topic of education is surprisingly popular. The readership here seems to have a huge interest in how the next generation of programmers comes about -- from kindergarten through grad school. While I infrequently write about education (I'm guessing 10% of my posts are about education), probably 25% - 35% of the comments are on education-related posts. If the feedback wasn’t so darned amazingly insightful, I would almost think of this as a “troll” topic. It is really cool to see how much vested interest you seem to have in the next generation!
  • Rants get few votes and little commentary. Point taken. I am actually rather embarrassed at some of my rants from a year or two ago.
  • Most readers use mainstream tools and languages, but few of them are happy with them. It's a sad state of affairs.
  • Most readers want to be working in a more “Agile” environment -- or at least they want more direct access to the end user. At the same time, I get the impression that few readers believe that their organization is capable of not mangling and botching “Agile,” and therefore see the need for a more “Waterfall” approach. This jives with my experience as well. (Perhaps I am just projecting my beliefs onto the readers with this one.)

There is one last conclusion, which I am saving for next week. Here are a few hints: There is a "sleeper" topic out there that I write about a lot; it receives little feedback (unless I write about it from the angle of something else that people care about like language or tools), and "industry experts" are burning a lot of bytes writing about it too. If you listen to the experts, this is the topic of the rest of this decade and all of next. Feedback in the TechRepublic forums, elsewhere, and all over indicates that most developers could not care less. Next week, I will be closing out the year (or starting the next one!) with this topic. I am sure you can all guess it already.

Happy holidays, and have a safe Christmas and New Year’s!

J.Ja

About

Justin James is the Lead Architect for Conigent.

27 comments
Tig2
Tig2

As a new blogger, seeing your commentary is helpful. It gives me a sense of what to watch for. As I no longer write much, I find your blog interesting as it keeps my brain working and gives me a sense of what is really happening. And your recent discussions regarding Agile and the availability of the end user in the design phase have had me thinking. I am not a big fan of Agile as a methodology but can see where it can have a great positive impact on the success of a project. Unfortunately, there are some downsides that require that the PM really be watching the team dynamic and insure that no one gets knocked off course.

NickNielsen
NickNielsen

Although I haven't done any serious code work since Pascal and dBase IV, I still appreciate the work that goes into a well-written program. Or a well-written article.

CharlieSpencer
CharlieSpencer

I never noticed the "thumbs up" button until you mentioned it. I knew it was there for answers to questions, but didn't see there was one for other content. Thanks. How 'bout this SC winter weather?

Justin James
Justin James

Glad you are finding it useful! Regarding Agile... I am torn. I hated it for a while, and then I realized that it was trying to accomplish formally what I had always done informally, which was get the end user dictating the requirements to the programmer, instead of having a thousand layers of "communication" between the endpoints. It is sad, but things really cannot work this way for most companies, most end users, or most programmers. So while I like the Agile concept, I feel that for most shops without handpicked folks, and who don't cherrypick the marketplace for the best customers only, Agile can be, at best lip service, and at worst, someone will try to seriously follow it. J.Ja

Justin James
Justin James

It's good to know that you like the work! J.Ja

Justin James
Justin James

I heard it summed up perfectly once: "the only place in the world where you will consistently turn on the heat and the A/C in the same day." It's so true. I miss snow though, growing up in NJ and all. I even miss driving in it. :) J.Ja

NickNielsen
NickNielsen

If we get some, we'll have had it all in only seven days... edit

Tig2
Tig2

Doesn't work, never has, never will. I know a project using Agile. The Application Architect- who is also the SME- can't get requirements. So he wrote his own. Now he can't get them ratified. Multiple meetings later, they are still arguing about what font should be used to produce the requirements document. And so it goes. A duck is a good example of a single person defining the direction of a project. A platypus is a good example of design by committee.

rclark
rclark

Right now we are going through a period of massive change based on user input. While I applaud the inclusiveness, I really worry about the value and long term stability. For day to day operations, it works wonderfully to focus resources on projects that actually make a difference. It saves lots of money and time in development, implementation and training. But taken too far and you have a system that is locked into your business practice as it was last year, not what will be needed next year or five years from now. Guaranteed obsolete.

NickNielsen
NickNielsen

I grew up in New York, between Schenectady and Oneonta. The only thing about snow that I don't miss is shoveling it! I do have fun when it snows here. I'll bundle up, make a pot of coffee, and sit on the front porch watching people try to drive on highway 1.

Justin James
Justin James

That's exactly right. It should have been a slam-dunk project, but instead it was (and still was, years later) never finished. You look at that and thank your lucky stars that you weren't put on a real project. Then again, with my last employer we were also implementing a government form, and we had a lot of slow downs with that project as well. A large part of the problem is that you need to ask a lawyer about every little detail, but chances are, the lawyer doesn't understand enough tech to make a good determination. A sure sign of this kind of disaster is when the SME keeps using the word "form" to refer to the HTML page that takes input, a PDF of the document (both softcopy and hardcopy) as well as a printed version of the original document. And then, when provided requirements and specifications, provides zero information as to which usage is meant at any given time. For example: "The form is sent to Operations for review. Upon reveiw, they mark is as 'Accepted', 'Not accepted', or 'Pending review' and the form submitter is notified." OK, so does someone fill out the HTML form and hit "submit", and someone goes to an online interface to mark the form's status, and the submitter gets an email with the status? Or do they print it, fill it out by hand, mail it in, and get a response mailed back? Or do they take the PDF, fill in the fields in the PDF, save it, email it in, and get a response through email? Like I said, someone giving requirements like that has a 100% chance of mangling them. These are the folks who forget what they asked for. Actual conversation I had a few months ago: Customer: Why did you do it like that? Me: Because you asked me to. Customer: No I didn't, why would I do that? Me: Here's the email you sent me. I don't know why you asked for it, and this is my response asking for a confirmation since it made no sense. Here is your confirmation email. Customer: Well, this makes no sense. Me: I know, that's why I confirmed that this is what you wanted. Customer: I don't know how this happened, but we need to sort this mess out. Huh? Do you have any confidence that this person will provide proper and accurate requirements and specifications? It's this kind of garbage that this shipping form project got tied up in... J.Ja

NickNielsen
NickNielsen

The data is prescribed by law, there's pretty much a single world-wide standard form involved and the actual stakeholders in that project were the HazMat certifiers. They should have been the ones calling the shots; 49 CFR holds Hazmat certifiers [u]personally[/u] responsible for every shipment they certify.

Justin James
Justin James

Simple project... took me 3, 4 months to get the list of requirements (which amounted to, "take this paper form and implement it exactly how the form says it should be implemented"). I coded it up in under 3 weeks, including some fairly complex logic for validation (it was a HAZMAT shipping form). It never got approval to go live. The last I heard (2 years after I left there, 3 years after the project started) it was still in limbo. Never mind the fact that it was estimated to save hundreds of thousands of dollars, hundreds of hours of labor each year, and ensure much better adherance to federal law. The problem? More than one "stakeholder", all with packed schedules. It was impossible to get everyone in the same room at the same time until you booked a month in advance, and even then there was the definite chance of someone cancelling at the last minute. As best I can tell, the refusal to trim down the list of "stakeholders" to just 1 or 2 people instead of using that project as a proxy for an ongoing personality battle has cost that company millions of dollars by now. J.Ja

rclark
rclark

And 80% of them still fail. You put all your eggs in one basket and hope you have an omlet at the end of the ride. Not for the faint of heart. The long implementation is much less risky, but scope creep, budget overruns, and never ending implementations are routine. So you either go with the all or nothing, or you pay to play. They both have their attractions.

Neon Samurai
Neon Samurai

a. easy to use b. efficient c. secure d. Windows98 (counts as two) 1.__ 2.__ [got that one from my login fortune-mod this morning and had to share]

seanferd
seanferd

I think that was a neat and brief observation, summing things up nicely. ...And now a comment from someone outside the industry: Sometimes politics destroy the best thought out plans of a few good professionals. IT needs to be able to take direction from executives and users, and inform them about what is possible within reason. IT also needs the proper staff for implementation. Executives need to understand what they want for the business, and be able to impart this to IT. Users need to think about what they really want, and limit the scope of their requests. Too much "Wouldn't it be cool if..." will kill any good project. Then someone needs to make a final decision on the form of the project, and s/he needs to be responsible for it, and be held responsible for it, within the scope of their decision. (That is, s/he is not responsible for someone else's bad coding practice, or bloat that rammed through bypassing her or his authority.) Flexibility may be the name of the game in some environments, but if you flex something enough, it just might break.

Justin James
Justin James

That description of "snap implementation", I've done that before, but never knew it had a name other than "hold on tight and get ready for the phone to ring at 2 AM". :) I would imagine that the rate of IT burnout, failed projects, and user frustration are higher than the already high industry average for you. You are right, the problem is not communications. The problem is this case is that the business wants (needs?) to change every 2 minutes, but they also demand that IT keep up. IT *can* keep up that pace... just not with projects that big! Either businesses need to slow down, or they need to back off of IT. But they can't have both, at least not reliably and cheaply. J.Ja

rclark
rclark

Perhaps more a failure of vision. I work in healthcare and everything changes so rapidly. To compensate, we have gone to a Just In Time model of software, where you replace anything that is out of date. On the other side of the issue, bloatware is so expensive and complex that it takes a lot of project management to successfully install and train. By the time the implementation is complete, you have an outmoded system that doesn't meet the current needs. This leads to more upgrades and changes, but those have to wait for budgets and planning. So we see a camel ride of software progress. Each step we take is jarring but covers a great deal of distance. One method currently being used is snap implementations. The new software is loaded on the servers as if it is a brand new install and the old system is just shoved out of the way when the snap is called. Then you spend months to years backloading historical data or running dual systems. Sometimes it works, sometimes the old systems just fade into the background until they finally are no longer justified and then are scrapped. I don't know what the answer is, but both the long implementation with it's personnel turnover issues and increased training costs, and the snap implementation with it's risk of failure and chronic under training are not comfortable paradigms to live with.

Justin James
Justin James

The end users know the process as it truly stands "on the ground" right now. They are the ones who can tell you how they do their jobs. Their managers will tell you what they think their people do, which is really a horrendous mixture of wishful thinking (the documented process with the changes each manager thinks it needs) and covering their own rear (what they tell their boss that they are doing). Anyone past direct manager has no business pretending to know what currently occurs. That being said, the "higher ups" do know what the business needs to actually happen! This is one reason why so many projects crash & burn. The programmers are given requirements generated based on the business needs, and then the users get the code and they say it has no bearing on their jobs. We all know this scenario. But why does it happen? Because the people who gave requirements to IT didn't truly work with the end users to see what really occurs, they just gave IT what they think should happen. And no one clued in the users, "hey, what you do now is a waste of time and money. What you are doing does not meet our requirements, and when the new software package is installed, your job will change significantly." And then IT looks dumb and "out of touch" with users. Agile formalizes the removal of these barriers. Which is why, as you say, you end up with a system locked into what your business was doing last year. :) J.Ja

Justin James
Justin James

Glad you enjoyed the article, even if it is not in your field! J.Ja

Justin James
Justin James

Glad you enjoyed the article, even if it is not in your field! J.Ja

Justin James
Justin James

Glad you enjoyed the article, even if it is not in your field! J.Ja

NickNielsen
NickNielsen

SC got a major snowstorm (I measured 11 inches at my house). School was out for three days and some students didn't come back to school until the following Monday. The state was essentially closed for those three days and operated impaired for another week until it all melted. The same storm in New York [i]might[/i] have resulted in a single snow day, but most likely only a late start.

seanferd
seanferd

Cleveland, OH. Personal favourite: I-71. Folks in this region of Northern Ohio, upon the season's first snow, will act like they have never seen the stuff before. Driving becomes erratic and slows to a crawl. After 2 days or a week, half the people are back to driving way over the speed limit (too fast for conditions), and some folks are still driving way to slow. Many are driving in the wrong lanes for their speed, changing lanes like they have racing tires on perfect pavement. The other thing is that very few people are equipped with shovels or lock de-icer, and many will not clean off their vehicles properly or let windows defrost, and don't dress for the weather. I love getting hit by a 2 foot thick slab of snow and ice off the top of a van on the highway, I'm a glutton for punishment. So how's that for a way off-topic comment on a technical blog? BTW, I always try to give a thumbs up for anything interesting, even when it doesn't apply to my work (like a lot of stuff on TR). I just wish that I could give a thumbs up to a good answer to a question that has been posted inside of a discussion (that is to say, not posted as a starter on a new question thread). Excellent article, Justin.

Tig2
Tig2

Having been born and raised in Southern California, I knew that snow was picturesque and distant. It did NOT visit your house. Until I moved to Washington State and learned that not only could it visit your house, it could drop traffic to a complete stop and cause people living on Queen Anne hill to hike home. We were allowed to use whatever traction devices we wished. Many of us had both street parking and driveway parking- and needed both. I moved to Phoenix and learned that people there were terrified of raindrops. I also learned that it was possible to get a significant percentage of the yearly rainfall total in about 20 minutes. So I moved to Minneapolis. I did all the right things, having lived in Washington. I bought snow boots and a brush scraper for my car, I made sure to have a winter coat, I learned to dress in layers. The first winter was tough, the second was not so tough, the third- and coldest of the three- wasn't even a blip to notice. In 2000, I drove to Connecticut for my Gran's 100th birthday. Family was collecting from all over the U.S. It was February. I left in a mild snow that became a snowstorm by the time I reached Illinois. The trip took me about three days. When I reached Connecticut, the temps were in the high 30s to low 40s. The weather was sunny and beautiful. And my entire family was bundled in sweaters and layers and stayed close to the fireplace. And I learned that things that I take for granted- a snow shovel in your trunk, the emergency kit, lock deicer- are not things that EVERYONE knows about. In fact, there is a large percentage of people who have never experienced temperatures below zero- much less double digits below! Just accept it, Justin. There are people who know snow. For the rest, picturesque and distant is just fine.

Justin James
Justin James

My first winter here, I went to the BlockBuster one night to rent a movie. I waited 45 minutes to check out, everyone had PILES of films and it was like a Tuesday night or something. Odd. I went next door to the Food Lion, the place was devoid of bread, milk, and eggs. Very odd. The lines were a mile long, people buying staple food products, toilet paper, batteries. I finally asked someone what was going on, they told me that a snowstorm was predicted. How much? "Could be as much as an inch!" I was incredulous. They close the schools on the *rumor* of snow. Then again, they put on goose down jackets when it hits 50. I am still trying to figure out why the WalMart here sells ski masks, on that note... J.Ja