The Self-Taught Programmer

Recipes from real-world experience with

Archive for the ‘Best Practices’ Category

Programming Zealots

leave a comment »

I was reading a blog post the other day — well, it was more of a rant, actually — about the evils of using regions in your .NET code. The guy had joined a team that used regions as one of their programming conventions, and he refused (rudely, I thought) to abide by the team’s policy. I thought some of the authors reasons were valid, but some not so much. What bothered me about the post was that he not only told why he didn’t use regions, but also why no one else on the planet ever should, and that if you do, you are a “bad programmer“.

This took me back to my early days in programming. I had been working in ColdFusion for a while and the guys at Allaire and then Macromedia had started to add some semi-object-oriented constructs to the CF language. Up to this point, I had only worked with procedural languages and had no education in OOP, so I was trying to teach myself how to use the new constructs AND how to program in an object-oriented way while still trying to earn a living.

The CF programming community is not large, and there are some real “rock stars” there — opinion leaders that everyone looks to for help and advice. They spend a significant amount of time blogging and answering questions on the forums, and I sought their advice many times. Many of these gurus are very nice and patient with self-taught programmers, thank goodness.

There were a few, however, that I called “zealots”. To these guys, regardless of language used (CF, Java, C++, etc.), there is a “right” way programming, and God help anyone who does things differently or disagrees with their “orthodox” way.

Contrary to what every good teacher has said to me, the zealots believe there ARE stupid questions. Look through any forum site where programmers go to seek advice. You won’t have to view too many threads before you come across a question asked by a programmer who is trying to solve a problem but is being attacked because the very premise of the question offends a zealot in some way.

So after getting flamed a few times with my own “stupid” questions, I became afraid to ask anything. Not the best way to learn, right? I resorted to “lurking” in the forums and studying 3-inch-thick books. And doing. Lots of doing.

And one thing I learned is that the “zealots” are wrong. There is best practice, of course, that we should all strive to follow, and there are plenty of great and helpful design patterns. But these are tools that have to be applied in the right situations, and ignored when another way works better. What works for one person or team or project may be the wrong approach for another. I believe practicality trumps orthodoxy.

The “regions” rant I mentioned earlier doesn’t have anything to do with design patterns, but it is still a good lesson here, because it is an example of how people’s brains function differently from each other. In my case, I am much more effective if I can hide portions of the code that are not directly and immediately being worked on. I can focus so much better if it isn’t showing. I also find it easier to dive back into a class when I come back to it after several weeks or months and it is structurally organized into functional regions.

Zealots like the blogger writing that rant can only see the way they think, and their way is the “right” way, dammit. So if I do something different, I must be a “bad programmer”.


Written by Jim McMullen

May 23, 2013 at 10:10 am

Should You Use 3rd-Party Controls and Frameworks? – Final Word?

with 2 comments

I’ve done some more thinking about whether or not to use 3rd-party controls (see my original post, and this follow up) and I believe I have some “rules of thumb” that make sense now.

My re-evaluation of my position on this has come because the EntitySpaces team announced that they would no longer continue the framework and would make it open source by the end of 2012. EntitySpaces is an ORM framework that I have used in several projects.

Criteria 1 — Is the control/framework/software integral to the functioning of the application?

If we are talking about a user interface control such as an enhanced 3-state checkbox or a text editor, the answer is “probably not”. In most cases, if absolutely necessary, you can drop-in a replacement with minimal fuss. Go ahead and use it.

If you are considering something like an ORM or javascript framework, you may be weaving it into the application and replacing it may be very painful or even impossible without re-writing big pieces of your software. You must consider Criteria 2.

Criteria 2 — How big/mission critical is your project?

If you are creating an in-house or personal project, just about anything goes. You can and probably will refactor it over and over as it is developed and being used.

If this is an enterprise or other mission-critical system, then you must be much more careful. You must consider Criteria 3.

Criteria 3 — Is this a new product?

If it is, you should probably wait until it has been vetted by the developer community and the kinks worked out. The first version of Entity Framework is a good example, even though it isn’t “3rd-party”.

If it has been around a while and has gone through several versions, that’s a good sign. But you must consider Criteria 4.

Criteria 4 — What kind of commercial or community support is available?

Look for blog posts, knowledge bases, wikis, and especially user forums that answer questions about the use of the control/framework. The sheer volume of posts will tell you something about how accepted and used controls/frameworks are. If you find that forums only have a few dozen posts, or only a few posts each week, then that tells you the user base is not very large, which is a red flag.

You should also note how quickly questions are answered, especially by employees/developers of the controls/frameworks. This can be critical to successful integration with your project.

Look for official documentation. Generally, the better-written and more complete the documentation, the more professional it’s development was.

With things like frameworks and open-source software, it is a good idea to look for any books written about it. If a publisher is willing to put out a book, then they believe the software is going to stick around for a while so they can sell more.

Criteria 5 — Get a second (and third) opinion

If you can evaluate the first 4 criteria and feel good about the control/framework/software, then you still have some work to do. If you are working on an enterprise system, you will need to make a recommendation to your team and ask them to research the product independently. You should look for reviews of the product and ask your own “does anyone have experience with…” questions on relevant forums.

The reason for this extra step is to avoid getting swept up in the hype surrounding the control or framework — and there is plenty of this.


So where did my analysis of EntitySpaces fail?

Well, truthfully, ES is a great piece of software. It has very few bugs and functions just as advertised. New versions were released 2-3 times/year. The commercial support was top-notch as the ES team was ever-present in their support forums. The cost/developer was very low.

In the end, what it lacked was widespread adoption by other developers (although there was no official announcement that this is what defeated the company). While I noticed that user questions in the support forums were answered completely and promptly, I didn’t pay attention to the low volume of posts. That should have disqualified it for my enterprise application — although not for smaller projects. And I will continue to use the open-source version for those because it is such a time-saver.


Written by Jim McMullen

October 26, 2012 at 2:51 pm

Should You Use 3rd-Party Controls and Frameworks? – Follow-Up

with one comment

The very next day after I wrote my original post on using 3rd-party controls, the EntitySpaces team announced that they would no longer continue the framework and would make it open source by the end of 2012.

Yikes! Now what?

I have 2 choices – do nothing with my existing code and continue to use ES after it goes open source, or replace it with something else – maybe Microsoft’s Entity Framework or NHibernate.

The downside of continuing with ES is that I believe it will lose support and wither away as an open source framework. When the next iteration of the .NET framework comes along, ES may no longer function correctly, and there may not be anyone working to fix it.

For an ongoing, commercial project like the one I am working on now, I’m not sure this is the best option.

The downside of going with NHibernate is that it doesn’t save that much time over the built-in provider model. And I could be wrong, but the MS Entity Framework doesn’t seem to have gained very much traction with developers, so I’m not confident that it will continue to be developed and supported, either.

So I’ve got some thinking to do, and some research, too.

Does this change my thinking about 3rd-party tools? Not really. I’ve saved myself and my clients/employers thousands of hours of development using EntitySpaces, and the applications are still very functional.

Truthfully this really only affects my most recent, in-development projects. And yes, it will cause some pain for me on those.

Written by Jim McMullen

September 21, 2012 at 5:53 pm

Should You Use 3rd-Party Controls and Frameworks?

with 2 comments

When you first start programming in a language, be it .NET, PHP, JAVA, or whatever, you tend to stick with the built in functions and controls. This makes sense, because you are learning how it works, what its strengths are, and where its limitations will trip you up. But every programmer at some point will spend hours or days trying to bend the built-in functionality to do something that a project requires, and think “there has got to be a better (easier) way!”

This leads to web searches and discovery of 3rd-party controls and frameworks that will (or almost will) accomplish the goal much easier than trying to hand-code new functionality using built-in controls.

For me, this happened in .NET when I got fed up with an overly complicated data access layer in a project I inherited. I understand the strength of the .NET provider framework, and the strong arguments for doing all database access using stored procedures, and the also strong arguments for having a business object layer between the UI and the data access. But geez, for a single programmer or a small team, I found this model to be very cumbersome and frustrating. Every time I needed to add a column to a database table, I found I had to spend hours updating the data access and business object layers. I was not “agile” in any way.

In my frustrated internet searches, I found recommendations for Object-Relational Mapping (ORM) frameworks, and in particular, I tried EntitySpaces ( This framework automated the development of almost the entire data-access portion of my project, saving me many, many hours on that one project alone. The licensing cost was minuscule compared to my hourly rate, so it also made financial sense. Of course, EntitySpaces also has its own limitations, but it was right for that project, and I went on to use it in many more of my projects.

Then a few weeks ago, a post in the EntitySpaces support forums noted that the ES developers hadn’t been very responsive lately in answering questions in the forums. A few of the ES users were starting to get worried that maybe development on ES would be slowed. Given the ambitious release schedule of the ES team, and the number of paid users they seem to have, AND the very high quality of the product itself, I would say it isn’t likely.

However, this points out a problem with trusting in 3rd-party frameworks and controls. You could rely heavily on a control or framework, only to find that it is discontinued either in the middle of a project or during later upgrade cycles. With something like a customized drop-down control, this isn’t the end of the world. But with something as fundamental to your architecture as an ORM framework, what do you do then?

Most of the time, there really isn’t a problem. You can keep using the 3rd-party control/framework just fine and continue your development. Where you might run into problems is if you upgrade to a new version of the base software (like going from .NET 2.5 to 4.0 for example), and the 3rd-party control/framework “breaks”. If that happens, you either have to stick with the old version of the base software, or replace the 3rd-party control/framework with something else.

The trick, I think, is to do your research – find 3rd-party controls that have been around for a while, gone through significant iterations over time, and have a good following among developers. I tend to think that for-profit controls/frameworks are more stable than free or open-source ones, because I have been burned by using free controls I found on the Internet that the original developer NEVER updated – or worse yet, closed down his product/support page.

In the open-source community, there are some really great projects that can help you get your projects done faster and better. Just be aware that there can be a “what’s hot right now” mentality — I used to develop in ColdFusion, and there seemed to be a new open-source CF framework popping up every few months. Uggh. Stay off that roller-coaster and employ the same criteria I mentioned above. Use the ones that have been around for a while and don’t seem to be fading away.

If you go with controls from one of the big for-profit companies like Telerik or DevExpress, I don’t think there is much danger of them disappearing any time soon. But you have to be willing to shell out significant $ for annual licenses and upgrades to keep current.

Do they add to or save on your development costs? Do the math (use your company’s hourly rate to do the calculations)… if you would spend less developing your own solution, and it works and looks just as good, then buying 3rd-party controls would add to your costs. On the other hand, if developing your own solution would take more time (and therefore cost more) than the 3rd-party controls, then it’s a no-brainer — especially since you can probably use the controls on more than one project.

(And I don’t mean to spread negative rumors about EntitySpaces… seriously, this is one of the best products I have ever used for development. I HIGHLY recommend it.)

Written by Jim McMullen

September 20, 2012 at 3:38 pm