I’ve been thinking for awhile now about this post and I’ve been unsure of exactly what needs to be here.  I know I’ve done a lot of maintenance work.  It’s inevitable.  You name the field and chances are we’ve developed something for it.  A lot of the software we develop we do so because there just isn’t commercial off the shelf (COTS) software for the business process.  COTS is for the broad market.  So customers come to us when COTS doesn’t meet their needs.

Which gets us to maintenance.  We try the best we can but in any software application there will be bugs.  It is inevitable, it is a fact of life.  Unless you are just writing a “Hello World” program there will be people who use your product in ways you didn’t expect.  We have had clients who take the application we’ve written for them and walk away.  Not because they’re unhappy but because the cost to fix every single bug and add in every feature they want can often be prohibitive.  They’re happy where the app is and that’s good enough.

Most clients stay with us for a maintenance tail.  They prioritize the bugs they want fixed and features they want added and budget accordingly.  We want happy clients, it’s that simple.  The happier they are with us the more work they bring to us.  This is common across all businesses, whether you’re a dry-cleaner or doing software services, a happy client is good.

So in software services how do you make a client happy?  In my experience it’s been minimizing maintenance tail costs.  But how do you do this?  I’m going to try and sum up where I have noticed problems.  I could reprint Code Complete here and say, “There, that’s how you do it” but that would be meaningless.  The point of this post is to focus on a few key points.

1.  The obvious:  Requirements, requirements, requirements.
As much as possible try to impress upon your clients the importance of requirements.  The more requirements analysis and design that is done up front before even beginning development the cheaper the maintenance tail.  It’s fact the earlier you find a problem the cheaper it is to fix. (Code Complete, Table 3-1, Average Cost of Fixing Defects Based on When They’re Introduced and Detected)

The biggest problem with this?  Most of the time clients don’t know what they want.  That’s right, they come to us and say, “Well, I want an application that does this.”  But what does that mean?  Does this need to mirror an existing business process?  Is it something completely new?  Do you have an idea of how the process should flow?  Do you know where you get your data and where it should go?  What kind of reporting are you going to need? (Customers never know that last one)

A lot of time we end up building up an existing business process in order to understand what needs to be developed for the application.  That’s okay.  I can accept that business analysis may be a part of the job.  So this is key:  (most of the time)  Clients don’t know what they want.  They will usually have a generally vague idea but you will have to help them.  Try to come up with a basic set of requirements.  Next, at a minimum, whip out Visio (there are better products out there but Visio is probably the most common) and throw together a few pages of the app.  Put together some sort of flow.  Help them bring their vision to reality.  Only then will they really begin to understand their own requirements and process.  Only then will they see what’s there and what’s missing.  Most clients can’t envision software.  They’re paying money for something that is completely virtual and just can’t see the final product.

Now, this is all well and good.  The problem is that a lot of clients don’t want to spend several weeks (or longer) designing the app, they want to get moving on it.  This leads to iterative development.  It’s more expensive.  But done properly I’ve still had happy clients.  Prioritize parts of the application.  Model a couple of those pages, build it, move on.  You will have problems.  I had one client who missed telling us about a key part of data for the app.  The ERD we had didn’t support this new data so we had to build out some new tables and fix everything.  This was after we’d done requirements and modeled the pages.  It wasn’t until the app was in beta that he went, “Oh, and you need to put this in there.”

2.  Naming Conventions: Use it, love it
This is going to sound stupid but one of the biggest problems I’ve had coming in to maintain an app I didn’t design or build is naming conventions.  Even if the names are consistent and meaningful, when there is no standard across an application where multiple developers have been working on it, it takes way too long to understand everything.  I’m not saying that your company should enact a strict naming convention company wide.  That would be nice but it’s not reality.  Your project lead, however, should.  Even if you’re working under different project leads you need to adapt.  This is especially true in this polyglot world of development.  At one time I was working on a PHP project, a java project and a C# project.  Each has their own naming conventions.  Yes, it took longer when I had to switch projects to re-orient myself but that in and of itself is the nature of polyglot programming.  I know that when someone comes behind me to maintain the app (and in a lot of cases it’s even me) it is a hell of a lot easier to get going on maintenance when there is some sort of naming convention across the app.

So what do I mean by naming conventions?  Method names, event and delegate names, variable names.  If it takes a name there needs to be a standard.  Whether it’s public, private, static, constant, an enum or class, there needs to be a standard.  The only place I haven’t seen a need for naming conventions is internal to methods.  If the app is coded right and adhering to basic OOP methodology variables internal to a method shouldn’t be around that long.  They still should be meaningful but I don’t care if you want to put an underscore in front of your internal variables or not.  I don’t care if you want to capitalize them or not.  Anytime I have to walk through from class to method to class to method to delegate to method there better be some sort of convention.  Otherwise it costs the client money.  There will always be some sort of spin-up when entering maintenance.  Just try and minimize it.

So you’ve got your requirements and naming conventions, what’s next?

3.  OOP, if you use it, use it
The biggest trouble I’ve had, excepting those mentioned above, are projects where developers seemed to take a procedural approach to OOP.  God classes and methods (functions?), poor use of inheritance and virtually no use of interfaces.  This makes maintenance tough.  I have to admit I myself was bit lacking in this area out of college.  Sure I took an OOP class, sure I had the theory but applying the theory is wholly different then having the theory.  And I’m not the only one.  It seems one of the universal constants having new engineers on my team fresh out of college is that they can’t apply OOP.  This often also applies to self-taught programmers who many times don’t even have the theory.

I want a black box (Code Complete, Encapsulate Implementation Details, Information Hiding).  When I step into a method during troubleshooting I want to only go into that method once.  There after I want to trust that the method works as intended.  I want a method to only do one thing and not affect parts outside of itself.  If I have a login control it should only be doing login.  I want a class to default all properties (getters/setters) to private.  I don’t want those variables being changed outside the class unless they need to be.  I want interfaces(Code Complete, Form Consistent Abstractions).  It seems like this is the least understood by programmers straight out of college.  So often new engineers like to inherit and override.  Obviously this has it’s time and place.  But think if this really is needed or if you just need to create an interface (Code Complete, Inherit-When Inheritance Simplifies the Design).

I digress, I’m starting to write out Code Complete.  If nothing else, use and apply Code Complete, 5.3 Design Building Blocks: Heuristics.

So how to fix this?  If you have an engineer on your team that you’re not familiar with do a code review.  Assign him a task and take a look at his code.  I don’t think I carry the title Senior Software Engineer because I such a great programmer.  Really I barely consider myself adequate.  I have seen a lot of code, written a lot myself, I lead teams pretty well as a project lead and clients like to work with me.  If you’re leading a project remember the code of the engineers underneath you is your responsibility.  Yeah, you might ruffle some feathers.  We programmers take our code personally.  We’re proud of it.  No different than an architect whose proud of a house he’s built or a chef whose proud of his food.

4.  Stay up-to-date
I won’t harp on this long because I’ve said this before.  Programmers use what’s available to them.  I love LINQ, but I know LINQ because I read about it before it was even released publicly.  I can do a lot of stuff easier with LINQ.  I love WPF, but I know WPF because I read about it before it was even released publicly.  I can do a lot of stuff easier with WPF then I could with WinForms.  If you don’t stay current there’s a good chance you’ll jump into a project where it’s using something you don’t understand.

5.  Code to maintain
I suppose this is really the heart of the issue.  What the hell does this mean?  Any adequate programmer should be able to jump into a piece of code and start working on bugs and adding features.  I’m not saying there won’t be a spin-up.  Of course there is going to be some spin-up.  But try and minimize that.  When most people are working on code they’re not thinking that in a year or more someone is going to have to come behind them and read the same code trying to figure out what they were doing.  But they should be.

Finally, I want happy clients.  That means minimizing maintenance.  There will always be maintenance, it’s inevitable.  But when I can jump into the maintenance tail of an project faster, fix bugs faster, implement new features faster than clients are happier and my job is easier.  And I like it when my job is easier.  It will always be challenging but I prefer challenging and fun to challenging and a pain in my ass.

I could keep going.  Someone could write a book on the subject (yeah, I know, Code Complete).  This post is just intended to hit a few top issues I’ve seen when maintaining code. YMMV.  You may have seen other issues that top this list.  Tell me about them.  Post a comment.

Later,
Brian

See
http://monotouch.net/

For those of us with an Android phone, Mono is running in Android, it’s just not very stable.  Here is a post of one of the Mono developers that compiled the Mono libraries from his Android from a debian install on his SD card.  Yes, in Android he’s running debian to compile Mono.  Is that not just sweet nerdy goodness?  While there is no time line for a full stable release of Mono on Android it’s in active development and, unlike the iPhone/MonoTouch option, it probably won’t cost a thing once it gets stable.

So what does this mean for us doing smart phone development?  When I was in college I applied for and received a grant for a platform agnostic project, written in java, to do streaming media, web cam and audio between multiple PCs.  For the first month of the project I developed on linux (don’t remember the branch) with Java.  I moved all the code to Windows and came across serious threading issues.  I fixed all those and spent the next month developing in Windows.  After that second month I moved everything back to linux and ran across serious threading issues.  For the last month of the project I compiled to a shared directory and tested on both linux and Windows.  I highly doubt there will ever be a stable environment that will work for all platforms, hardware is just too different.  MonoTouch has specific interfaces to the iPhone APIs.  Once Mono for Android gets stable I’m sure there are going to be wrappers for the Java APIs for Android.  But is this a bad thing?  Isn’t competition good?

Later,
Brian

Software Engineering Code of Ethics and Professional Practice (Short Version)

PREAMBLE

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

This Code may be published without permission as long as it is not changed in any way and it carries the copyright notice. Copyright (c) 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc.

What? No mention of Java.  I really couldn’t care about Solaris or SPARC.  What is the future of Java?

Thanks,
Brian

Until then here is a bit of xaml for self-referencing bindings.

<TextBlock
  Grid.Column="1"
  Width="75"
  Foreground="{StaticResource ActiveTabForeground}"
  TextWrapping="NoWrap"
  TextTrimming="CharacterEllipsis"
  ToolTip="{Binding RelativeSource={RelativeSource Self}, Path=Text}"
  Name="txtHeader"/>

As you can see I often use these with TextBlocks where I’m using text trimming. The reason being that, with text trimming, the text gets cut short if it exceeds the width of the textblock. This way users will be able to mouse over the textblock and get the tooltip containing the full value.

Where else would this be useful? Well, um, I don’t know since I only use this with tooltips on TextBlocks. But it is certainly helpful for that.

Enjoy,
Brian

(I love kicking it ol’school and using tables)

To the 26% that said no I say, “Good, you’re doing your job.” To the rest of you, “Get to work.”

I don’t often write opinion pieces preferring to keep the focus of this blog more on tutorial type posts, maybe because I don’t really consider myself any real authority. I do my job and in the course of my job I learn a lot that I want to pass on to other people.

So why start now? Well, this survey struck a nerve for me. Maybe it’s because this has some fingers in my post about Oracle and Java. In that post I reveled in the fact that Microsoft is able to keep the .Net framework moving forward at a fast pace and that, relative to .Net, Java has become fairly stagnant.

In Jeff Atwood’s post, The Two Types of Programmers he discusses the two types of programmers as mentioned in an article by Ben Collins-Sussman which says there are two classes of programmers, the “20%” and the “80%” programmers.

To this I have a serious problem. I spend a great deal of time reading the latest programming books, blogs and magazines. I do so because I want to stay current in my field. If I was doctor it would be expected that I would stay up-to-date on the latest research and trends in the medical fields. So should we as programmers.

Our job is to be the best programmers we can be. Fatigue should be irrelevant. Even if you are working in a world were the language features and APIs aren’t moving forward there is still a lot you can do. Read up on patterns and anti-patterns, if you haven’t read Code Complete, do so. I find the idea that programmers are perfectly happy to rest on their laurels completely ridiculous. Strive to become a better programmer, push yourself and your knowledge. As you become better at your job you will become a better person all-around. Knowledge is power.

If you stay current fatigue isn’t an issue. By keeping current incrementally there won’t be any fatigue. Start reading up on .Net 4.0 right now. By the time .Net 4.0 releases you will be pretty caught up and boom!, no more fatigue.

You may say, “Well, my job is to use this or that API or SDK. Knowing anything outside of that is irrelevant.” To that I’m calling “Bullshit!” It’s not about just writing code. If being a programmer was just about writing code then anybody could be a programmer. Writing code is easy. Writing code cleanly, efficiently so it’s easy to maintain, now that takes some skill. The best way to do so is to stay current.

Saying that you’re experiencing “fatigue due to the pace of Microsoft Technology introductions” is a serious cop-out. Staying current is your job because the more current you are the better programmer you are. If I was a fry-cook I’d want to be the best damn fry-cook on the planet, learn the lingo, find the right temperature for the grill so it cooks the eggs and burgers efficiently, work on recipes that taste good and can cook fast. I’m not a fry-cook, however, I’m a computer programmer. Being the best programmer I can be means that I have to stay current on new technology. Screw fatigue.

Thank you, that’s my time

high-pitched whine as I drop the microphone

This bit me at first so hopefully with this it won’t bite you.

If you have:

List<Product> products = new List<Product>();
products.Add(new Product { Id = 1, Name = "Cheese", Quantity = 2 });
products.Add(new Product { Id = 2, Name = "Wine", Quantity = 2 });
products.Add(new Product { Id = 3, Name = "Crackers", Quantity = 0 });

var zeroInStock = from product in products
                  where product.Quantity == 0
                  select product;

foreach (var stock in zeroInStock)
{
    products.Remove(stock);
}

you will get:

InvalidOperationException was unhandled. Collection was modified; enumeration operation may not execute.

This is due to the deferred execution of LINQ. The results of zeroInStock are not calculated until you need them. The problem is that if you attempt to remove an item from the list in which the result originated from the original list is now not valid for the LINQ query. So how do you combat this? With ToList(), ToArray() and ToDictionary().

List<Product> products = new List<Product>();
products.Add(new Product { Id = 1, Name = "Cheese", Quantity = 2 });
products.Add(new Product { Id = 2, Name = "Wine", Quantity = 2 });
products.Add(new Product { Id = 3, Name = "Crackers", Quantity = 0 });

var zeroInStock = (from product in products
                  where product.Quantity == 0
                  select product).ToList();

foreach (var stock in zeroInStock)
{
    products.Remove(stock);
}

Now this code works. In this example ToList() and ToArray() could have been used interchangbly since we’re utilizing var but you may need one over the other. By calling ToList() or ToArray() it forces execution of the query. This means that now you can change the original list all you want without any issues.

ToDictionary() works a bit different. You have to specify a lambda expression to detemine what the key should be for each given result. Here’s the ToDictionary() example:

List<Product> products = new List<Product>();
products.Add(new Product { Id = 1, Name = "Cheese", Quantity = 2 });
products.Add(new Product { Id = 2, Name = "Wine", Quantity = 2 });
products.Add(new Product { Id = 3, Name = "Crackers", Quantity = 0 });

var zeroInStock = (from product in products
                  where product.Quantity == 0
                  select product.ToDictionary(x => x.Name);

foreach (var stock in zeroInStock)
{
    products.Remove(stock.Value);
}

You can see here the lambda expression means that the generated dictionary will be made of KeyValuePair<string, Product>. Since the product is now the value of the KeyValuePair the foreach that removes products with zero in stock now uses the Value.

If you are going from dictionary to dictionary as in:

Dictionary<int, Product> products = new Dictionary<int, Product>();
products.Add(1, new Product { Id = 1, Name = "Cheese", Quantity = 2 });
products.Add(2, new Product { Id = 2, Name = "Wine", Quantity = 2 });
products.Add(3, new Product { Id = 3, Name = "Crackers", Quantity = 0 });

var zeroInStock = (from product in products
                   where product.Value.Quantity == 0
                   select product).ToDictionary(x => x.Key);

foreach (var stock in zeroInStock)
{
    products.Remove(stock.Key);
}

you will most likely want to just use the existing key as I have above. Now, this doesn’t mean you can’t change the key but for my purposes I just used the existing key since I can use that to just remove from the dictionary.

That’s all for now. Leave me a comment if you have any questions.

Brian

So what. I don’t care much what the writer says. Java is open source, so Oracle can’t “own” it in the sense they can’t control it.

to which I responded:

@Alberto,
Java itself is not opensource only the JDK. This means if you want to help to make changes to the core libraries you can but if you got a wild hair for some reason and wanted to figure out how to add LINQ to Java you couldn’t. See http://www.sun.com/software/opensource/java/faq.jsp#b8

This is an important distinction. The JDK is opensource, not Java. This means the future of Java is in the hands of Oracle and it scares me. Development on the Oracle DB itself has been rather stagnant. I’m not saying that there haven’t been new features added, just that Oracle hasn’t been making any big leaps forward.

I’ve had the unique opportunity for the last 6 years to develop professionally in Java and the last 5 years in C#, a man of both worlds. When C# first came out I was thinking, so what? I can do that in Java and do it easier and cleaner. C# had a lot of catching up to do. Fast forward 5 years and Java is so far behind the curve now. Development of the Java language has become stagnant. Like the Oracle DB, new features are added sure, but there haven’t been any significant leaps forward. Java has simply fallen behind. I just hope Oracle doesn’t do to Java what it has done to it’s DB and let it die a slow death. As pointed out by Andrew nearly all of Oracle’s business is with the government, and having worked on some government contracts I can tell you that is starting to slip.

As a new generation of IT moves into places of power they simply are not as enamored with Oracle as the old guard were and they are willing to look to other solutions.

So what does this mean? C, C++ and Perl haven’t had any new features for a long time. Does a language need to make leaps forward? C, C++ and Perl live in different worlds with different purposes then Java and .Net. Sure there are some cross purposes but for the most part they are separate. Java has to continue to innovate if it wants to stay a viable mainstream language. I hope that Oracle can bring innovation back to Java and yet worry that it doesn’t really care.

Brian

In thinking back, the only part of my comment I disagree with is:

having worked on some government contracts I can tell you that is starting to slip.

The reason I disagree with it is because, at this moment, the federal government and the DOD are still firmly entrenched in the idea that Oracle is the only way to go. So basically I’m saying that things aren’t starting to slip, at least not right now.

But I do firmly believe the next part of my comment:

As a new generation of IT moves into places of power they simply are not as enamored with Oracle as the old guard were and they are willing to look to other solutions.

My point here is that I think Oracle cares about Java because their tools are written in Java. But that is it’s only extent. Now that the JDK is opensourced I’m sure we’ll see some movement in the JDK but very little, if not nothing, in the Java language itself. This is really a shame.

There is no doubt that Java rules in the web application market against .Net and ASP.Net, just as there is no doubt that Apache rules in the web server market against IIS. Maybe that is fine for Java. Maybe Sun wants it to be consigned to a subset of the development market. But there are some heavy hitters in that market, Ruby, PHP, and Perl to name a few.

So why not try and carve out a significant share in all markets? Java has never truly had a significant share in the desktop application market. I feel it was held back by how bad AWT and then Swing were. In Java 6 it seems like they’ve tried to make some steps forward with the new desktop APIs but it doesn’t seem like that is enough.

6 years ago Java was an innovation. Now it’s merely stagnant. It’s APIs can’t keep up, it’s language features can’t keep up. With every new release of .Net I find it easier and easier to do everything. With every new release of Java I think, “That’s kind of cool but that doesn’t help me.”

There is a definite flaw there. I hope Oracle dumps a bunch of money into Java and really gets the development platform, from both the JDK and the language features perspective, kicked into high gear. It’s just that it seems that Oracle actually likes stagnation. If it ain’t broke, don’t fix it is their attitude. The problem is that, while that may work for the Oracle DB with their heavy paying government projects, it doesn’t work for Java.

Later,
Brian

Let me start off by saying I’m excited that I finished it. There is a lot of good information and there is no doubt that it is the standard for sound software developement principles. That being said, remember when you try to tackle this bood that it is a text book. Sure there are some interesting anecdotes about this and that. I suppose I should have been more thrilled about reading it but couldn’t drag myself to pour through it like I have some of my other software books. It took me a year to read Code Complete. During that time I re-read The Belgariad series, The Malloreon series, most of the Song of Ice and Fire series, and read for the first time Pro WPF in C# 2008, Effective C# and I’m almost done with More Effective C#.

So what am I saying? I know there are those of you out there that love Code Complete and read it voraciously like a good fiction novel. I couldn’t even read it like a good code book. Pro WPF in C# 2008 I read like a good fiction novel. I drank it in and loved it. Code Complete I just couldn’t do that with. As I said, it’s sound, solid developement principles I try to apply every day on the job. I learned a lot and will continue to try and apply the princibles of Code Complete. Simply because of that it is a reason to read the book.

If you’re like me and are struggling to get through Code Complete, spread it out, read a chapter and then take a break and read something else. There are 35 chapters in Code Complete. Read a chapter every two weeks, in between other books and it will take you just a bit over a year to read it.

What else can I say? 99% of the book makes perfect sense. Some of the code formatting seemed a bit off but I just let visual studio format my code for me. Ctrl-K + Ctrl-D, Baby!

Read it, grok it, follow it and your code will be better, cleaner and easier to maintain.
That’s all there it to it.

Brian