Skip to content

Lunacy has a name: OOP Is Much Better in Theory Than in Practice

I was doing more digging in the area of software development improvement and stumbled across the article “OOP Is Much Better in Theory Than in Practice” by accident.  (It was referred to by a Design Patterns/GoF anniversary article I was reading.)

While I believe that Richard Mansfield has a few solid points (like few people understand OO, it’s more intellectually challenging than procedural code (my words), etc.)  However, I fundamentally disagree that OO is not the right way for every mainstream business application to be written.  I understand that real-time systems, operating systems, and a variety of other specialized applications shouldn’t use OO as their fundamental design foundation, but in just about every other case, the benefits seem to far out weigh the down sides.

This is just a reminder to me that we have a long way to go to get everyone to understand not only the how of OO but the why as well.

Article: What are you teaching your software developers?

If your software developers are learning how to be software developers through their experience at your organization, perhaps you should ask what you are teaching them.

Most organizations don’t have a formal apprenticeship program for software developers. There is no journeyman for software development. However, most software developers today learn as much through their interaction with other developers as they learned during their formal education.

So if your software developers are learning how to be software developers through their experience at your organization, what are you teaching them? It’s time to evaluate what the software developers in your organization are learning.

The need for education

As an industry we still suffer from project failures, cost overruns, poor client satisfaction, and a general malaise. Failure rates for software development projects are wildly different depending upon who you listen to. Publicly reported rates vary from 5% at the lowest to over 70%. While neither of these numbers is particularly believable they illuminate the fact that there is still a problem. If software development was steadfastly producing quality software all of the numbers would be in the same range.

https://www.techrepublic.com/article/what-are-you-teaching-your-software-developers/

The Tivo Out of Box Experience is REALLY bad

It is amazing to me just how bad of an out-of-the-box experience that you can have with Tivo.  For all of the good things that the product does, it’s like there’s a completely different company managing their out-of-box experience.

I wanted to summarize for folks the situation that I ran into recently when I purchased a Tivo unit with DVD recorder for the church I attend.  I purchased it to record and store content from a specialized satellite subscription that the church purchased.

To start, you must use the phone line for initial connectivity and there is still no network connection on the unit I purchased.  You can add a USB-based network card, however, it’s a separate accessory that you have to buy.  Not a big deal in the grand scheme of things, however, it can make logistics difficult as it did for me.  To get the unit started you must complete the setup calls (not setup call as seems to be the common parlance.)

So I plugged the unit into a line that I thought was an analog phone line — it turned out to be a digital phone line — and the modem burned out… when the replacement unit arrived I plugged it into the line for the fax machine (which I new was analog).  It completed it’s first call and then asked me to setup the A/V sources.  I go back to try to tell it that I want to specify my sources, since specialized satellite wasn’t one of my options.  It forces me to make the 10 minute setup call again because I transitioned back before the call to change the sources.  I get to the same screen and eventually turn the unit off and take it back to the room where the satellite is connected.  When I plug it back in it forces me to go back through the setup again — including the phone call … which I can’t make because the phone is in another room.  (Are we beginning to see the insanity?)

So I decide I’ll bring it home where I have phone and video together and then move it back to the church.  That’s great.  I start the process all over and get through the first call and the setup relatively quickly.  (I was doing other things at the same time.)  Then it goes to make a second call.  After the third failed attempt I replaced the relatively long phone cord with a short cord.  It’s still not working.  Each attempt takes five minutes or more because it doesn’t restart the download and in fact it does a cleanup activity prior to starting.  Needless to say it’s a painful experience.  I have Vonage for one of my phone lines, the one I was using.  So I eventually tried the other line and it worked … and at the end it says that the unit will be working for between four and eight hours and I shouldn’t unplug the system until it’s done.  It doesn’t indicate how I will know if the unit is done, nor does it indicate if there’s a safe way to power down the system that won’t cause any issue.

What irks me most about this whole situation is that less than a dollar could have put a flow chart of setup activities in the box.  Something that would have shown me the steps I’d need a phone line for, the overall process, and how to deal with common issues — however, that level of thought wasn’t put into the out of box experience — in a company that spends so much time working on user interfaces, ascetics, and other “user touch“ aspects.  It’s unfathomable that they wouldn’t put more thought into the out of box experience.

I’m now sitting with a Tivo unit on my desk that needs to go back to the church.  I’ve invested hours getting the unit to work for something that frankly should have just powered on, started up and let me use it as a glorified VCR without any of the issues I ran into.

By contrast, I’ve had a replay TV unit for three years now.  The out of the box experience was easy. I had the option of using either a phone or the network.  As I remember it, there was a basic set of instructions for what was going to happen and what I needed to do.  It was an extremely installation…

Now I need to see if I can figure out how to get the unit to tape from the satellite feed back at the church or if I’m not done dealing with the setup process. At least I can connect it to the network, if I can figure that out…

The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP

Book Review-The Rational Unified Process Made Easy: A Practioner’s guide to the RUP

It’s very in vogue to describe your software development process as RUP.  Describing the current methodology as agile (XP, Crystal, Scrum, etc.) evokes too many questions, but describing the methodology as Rational Unified Process, more frequently RUP, leads to fewer questions but puts you ahead of those who are still running a waterfall process.  However, in many cases RUP isn’t really the methodology being used, it’s simply renaming some of the processes and artifacts that were done for waterfall with new names.

The beauty of the book The Rational Unified Process made Easy: A Practitioner’s Guide to the RUP is that focuses not on enumerating the artifacts that one might use with RUP but rather focuses on the core concepts, fundamental precepts, and spirit of RUP.  In this way it intentionally steers the reader away from the natural tendency to try to implement every artifact, to create the highest ceremony process possible.  It provides a balanced view on how to utilize RUP to run effective, successful software development projects.

It also contains a role-by-role review of RUP.  This provides a view of the process from each role’s perspective.  The benefit of this is to condense the amount of training that must be done to get everyone working on the same page.  While they can not be considered a direct replacement for training, the chapters are a good start to helping the team member understand what RUP is all about.

Even in a world enamored with agile, RUP still has it’s place.  It’s proven for larger projects, and provides a path to an iterative model — essential to every form of agile development.  If you’re trying to get to agile RUP is a good stopping point along the way — and the book The Rational Unified Process Made Easy is a good way to understand how to do RUP.

Good Quality Assurance Information

I’m preparing for a presentation to the Indianapolis Quality Assurance Association on February 16th titled “The Impact of Coding Standards and Reviews on Quality.”  I stumbled across a link that is titled Quality Assurance, but is really a collection of really good development ideas, some of which are quality ideas, but many are ideas for better development.  You can find the link here.

Good ideas like defensive programming, exception management, and others are woven throughout this document — it’s an interesting read.

Article: Effective Code Reviews without the Pain

Code reviews in most organizations are a painful experience for everyone involved. The developer often feels like it’s a bashing session designed to beat out their will. The development leads are often confused as to what is important to point out and what isn’t. And other developers that may be involved often use this as a chance to show how much better they can be by pointing out possible issues in someone else’s code.

Code reviews, however, don’t have to be painful.

Remembering the Purpose

Code reviews have two purposes. Their first purpose is to make sure that the code that is being produced has sufficient quality to be released. In other words, it’s the acid test for whether the code should be promoted to the next step in the process. Code reviews are very effective at finding errors of all types, including those caused by poor structure, those that don’t match business process, and also those simple omissions. That’s why they are an effective litmus test for the quality of the code.

The second purpose is as a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.

Read more…

Rant: Book Development Editors are a dying breed

I used to do a lot of development editing for books.  It was fun work.  You were able to see the impact on the books you were working with.  You could see author’s writing getting better as they started to get used to your comments.  They would quit taking short cuts.  They would begin to view the material from the reader’s point of view.

The job of the development editor in the book process is to “develop” the material.  In other words, the development editor is supposed to make the material better.  Development editors don’t do this by adjusting the placement of the commas or the number of capatilized letters (that’s the copy editor’s role.)  Instead, the development editor looked at the tone, overall flow, depth, and other broader issues.  They focused the author’s attention on these issues so that they could be improved upon.

What I’ve realized from the reading that I’ve been doing lately is that the development editors aren’t doing this today.  It’s likely because they’re too busy with other projects but still the abscense of this assistance for the author is painfully missing from many technical books today.

The book industry is right to be scared of the Internet and the way that we consume information these days, however, they’re not doing themselves any favors by shortcutting the development process in favor of books that are quicker to market.

I read a lot of blogs, articles, and shorter content on the Internet.  However, when I really need to have a thorough understanding of a topic, or I need to make sure that the information is right, I go to a book.  I use them as authoritative voices — however, this is challenging for me when the books have no more thought or organization to them than a typical one of my blog posts.

I wonder if the technical book publishing community will totally collapse before they learn what made Wrox what it was. Ok, before they went bankrupt.  The point is, however, that the brand of Wrox was powerful.  Having the opportunity to work with them (as a technical editor), I can tell you that they crafted their books.  The development editor was very involved.  They had the material run through two technical editors.  Everything was designed to get a quality product — at the center of that effort was the development editor who was managing all of the support that they were providing to the author.

Of course, the days where you could expect that a book won’t wander — that it will follow a clear, intelligible outline are long gone … Some days, I wish I could go back.

Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Book Review-Software that Sells: A Practical Guide to Developing and Marketing Your Software Project

Do you know why you don’t see a lot of negative reviews of anything in magazines?  The answer is simple.  Why print something that is negative when you can just as easily print something positive?  Well, the beauty of a blog is that I can post something negative if the item deserves it.  This is one of those cases.

I just finished reading Software That Sells: A Practical Guide to Developing and Marketing Your Software Project.  Actually, there were several sections that I couldn’t force myself to read.

The information contained in the book is trivial, obvious, and sufficiently non-specific so as to be non-actionable.  In other words, this is stuff that nearly everyone knows.  You could buy someone in your area a drink at the local tavern or pub and get a more coherent delivery of useful information.

While I do realize that there are some folks who are very early in their careers who might be able to find value in the broad coverage of topics, most people will find the coverage too trivial.  What is worse, in my opinion, is that the author doesn’t provide the reader good references to go find more information.  There are chapters on marketing and sales, but no references to other books that cover these topics in detail.

So, if you’re trying to figure out how to start a Micro-ISV (small software product company) you may want to keep looking for a good book.  (Micro-ISV by Bob Walsh is on my reading list still.  I’ll let everyone know what I think of it.)

dashboard

Fundamentals of Performance Testing

I’m in the process of writing an article for TechRepublic.com on the declining importance of performance testing.  Without getting into the articles primary arguments, I came to a realization that I felt compelled to share.

Most IT professionals have no idea how to approach performance testing.

I mean that both from the sense of they couldn’t do the testing if the needed to and also from the perspective that they don’t truly understand how it works.  The article for TechRepublic.com is, as most of my articles are, born out of experience.  I’ve noticed that way too many organizations get hung up on performance.  They avoid items which have been identified as non-performant but which make the development process much easier and therefore it costs less.

So in the interest of educating folks, here is a high level summary of what you should know about performance testing, the details will be in the article …

  • Performance Testing – Performance testing is really a set of related evaluations of the system including: responsiveness, throughput, and scalability.
  • Responsiveness – Responsiveness is how quickly the system can complete an individual transaction.  As the throughput of the application goes up responsiveness typically goes down.
  • Throughput – Throughput is the rate at which transactions can be completed.  Typically maximum throughput is the number that organizations are trying to find.
  • Scalability – Scalability is the amount to which various changes to the environment can impact the maximum throughput and to a lesser extent improve responsiveness.  Different changes can result in radically different effects on throughput expecially when the scalability is directly related to a bottleneck.
  • Bottleneck – A bottleneck is a performance constraint in the system which prevents the throughput from increasing.  Typical candidates for bottlenecks are processor performance, available memory, disk performance, and network performance.

I hope this helps.

Article: Choosing Between a User Control or a Web Part for SharePoint

I generally recommend that users don’t write Web Parts unless they have to. That confuses a lot of people since most people believe that you have to write Web Parts if you want to do work with SharePoint. This is only partially true.

SharePoint will only display Web Parts on a page. However, there are publicly available shims that allow you to write user controls and have them be displayed as a Web Part. From SharePoint’s point of view, the shim is a Web Part. From the point of view of the user control, the shim is simply a control in .NET that is including the user control.

http://www.intranetjournal.com/articles/200601/ij_01_20_06a.html [Website no longer available]

Recent Posts

Public Speaking