Robert on Software Development

Version control has been around long enough that even people who don’t work in IT are accustomed to it. A few weeks ago I was talking to a friend about “source control” and she asked what that meant. I explained how it works, and she said, “Oh, like SharePoint document libraries.” That made me happy.

While we IT developers have been using source code control for what feels like eons, some of us don’t think about using it at home. For a lot of the folks coming from the world of Visual SourceSafe, source control’s primary benefit is sharing files among team members; ditto for the document library check-out function that my SharePoint-using friend pointed out.

But as homegrown software projects grow more and more complex, it becomes even more important to have a source control solution for those projects. Such began my search for a source code management (SCM) tool. I knew up front what my basic features are:

• Version control
• Merging
• Branching
• Visual Studio integration
• Scalability (needs to support more users someday)

That’s not too much to ask, right? A quick Google search for “free version control” turned up Git, Mercurial, and Subversion. (There were other choices, but they were free only for open source projects.) At work, we use SourceGear Fortress, and I’ve been a user of Visual Studio Team Foundation Server for many years, but those products have costs, and for my simple projects at home, I wanted to minimize my cash outlay.

What I found with Git, Mercurial, and Subversion is that they are excellent tools but are way more complicated than what I need. I really want something with the relative simplicity of Visual SourceSafe but the power of something more like Subversion; this product does not exist without a cost. I really like Vault, but man, $249 for a single license?

I have a license for Visual Studio TFS, but it’s way overkill for just one user. I’d need to run it in a Virtual Server environment and that’s a lot more than I need.

Right after I decided to bite the bullet and use Subversion, I went to close the tab containing SourceGear’s website and something caught my eye:

A full-featured 30-day evaluation is available at no charge — and Vault is always free for single users.

Free for single users? Why didn’t I see that sooner?

Thus ends my quest for a SCM tool that is a) free b) easy to use and c) scalable. If I’m someday able to add another developer to my home project, then I can surely shell out the 249 bucks for an extra license. The Visual Studio integration is tight and I’m very used to it from my day job.

Please note: I’m not trying to slam SVN, Git, or Mercurial. Those are awesome SCM tools. But for the single user like myself, they’re overkill.

What personal SCM tool do you use? What do you use it for?

Business rules are the driving force behind every enterprise application, from the smallest (such as a Windows application to calculate bus-based shipping costs) to the biggest (such as an application that processes driver’s license renewals). Yet so much attention is directed toward how we build software rather than why we build software.

Take design patterns for example. Design patterns are very useful tools for building applications because they draw upon what’s already been done, so you don’t repeat the work of thousands of other developers. Not everyone is a fan of design patterns, so there’s a ton of discussion about their merits and pitfalls all over blogs, discussion forums, and programmer Q&A sites. The thing is, design patterns don’t make your software finished. They don’t drive the business side of software development; that is, a design pattern is not going to make your calculations for you. But nobody is talking about this. Nobody is talking about a design pattern for managing business rules.

It seems like developers and software architects are happy to just assume that the business rules are going to be taken care of in the process of building the software. We like to think about using ORM for the data layer and MVC for the flow control and SharePoint for the document lifecycle. In a lot of cases the business rules are a foregone conclusion; I know that if I’m going to develop an application that calculates bus shipping costs, I’ll get the formulae for those calculations from somewhere and I can worry about how they work when the UI/database/flow control/etc. are done.

My current customer has their business rules all over the place. They’re in stored procedures. They’re in ASP.NET code-behind files. They’re in ASP.NET pages. The rules aren’t documented anywhere. If I need to figure out how the fiscal year is calculated, I either have to ask the domain expert or dig around in several code files. That’s a relatively simple calculation. For some of the more complex rules, such as determining eligibility for reimbursement, it’s nearly impossible for me to figure them out on my own. The prospect of getting all those rules under control while fixing other bugs and adding new features is daunting to say the least. It will easily take years.

In future application development projects, assuming I get to be in on the design phase, I will ensure that the business rules are captured in a way that is meaningful both to the stakeholders and the developers. Windows Workflow is a great way to do this, for example. There are also enterprise tools from Computer Associates and Rational that will keep track of business rules (or rather, requirements).

Managing your business rules is a fundamental piece of IT governance. It’s a very important IT survival skill.

I love fatalistic blog post titles.

I have been brewing an idea in my head for a couple of months, since early October. The idea has germinated in my mind, growing from high concept ("It’s a site that does x") to more detailed ("It’s a site that does x so you can y") to pretty fleshed out ("It’s a site that brings together z so you can y and get x"). Or something like that.

But like all great ideas, mine sat in my head or served as dinner conversation for my bored friends. When the idea reached critical mass–that is, when I wished the application existed so I could actually use it–I knew I was really on to something. I decided to actually make my idea a real thing.

So I began to plan. And plan. And plan. I acquired hosting. I acquired tools. I set up source control. I set up issue tracking, and features tracking, and installed all the software I needed. I set up a separate development machine. I organized my home office to support my work. Once I got everything set up, I took a step back and admired creation: "Wow," I said. "Look what I did."

Which, of course, means absolutely nothing, because I’m in the business of creating software, and I hadn’t created a single bit of anything.

I don’t have a database design. I don’t have an architecture. Until a week ago, I waffled on ASP.NET webforms versus ASP.NET MVC. I had a host set up for a month before I canceled it in favor of another who offers URL rewriting, so at least I made a sound design decision there. My Visual Studio project has my web site project in it with empty code files. I have nothing.

In my rush to get everything squared away to support the development of my idea, I failed to actually do any development. Sure, it was necessary to get things in order: source control is vital, the database needs to be up and running, and so on. But that configuration is where I directed my initial project passion, and now that it’s complete, I have a false sense of accomplishment. In a way, I almost have to start over. I have to rekindle the passion for my project and direct the efforts into the actual creation.

Fortunately, I was able to realize what was going on before I let my idea enter the world of "I should have worked on that more," like so many other ideas. I think my project has real value and if I invest the time and energy it requires, it could become something very wonderful.

On a warm May afternoon in 2005, I sat in a conference room with some very smart people. We were discussing things like reference architectures, SOA, Solaris containers, and code generators. As members of a skunkworks R&D team at the company, we had to produce, and we made some great things. But what I remember most from working in that group and attending that meeting is that while we looked way up into the clouds for the next big thing, our feet were on shaky ground: we rarely agreed on anything. For example, none of us agreed on how a data layer should be properly constructed in an enterprise application. One person thought the built-in .NET tools were best; those tools have since been deprecated. Another person liked the monolithic God Class approach, where one class provided everything. I thought the specialized ORM tool built by the company–a data layer builder of sorts–was the best choice, since it offered the most configuration and decoupling.

In my new role here in Iowa, I’m in a situation where the data layer in a production application is practically nonexistent. The core business logic exists in stored procedures, and stored procedure calls are crafted mainly in the code-behind class files for the various ASP.NET pages. There’s also some stored procedure and SQL code in a massive static class. This approach is a maintenance nightmare. As a consultant brought in to get the product under control, I have to find a way to standardize the data layer without making a negative impact on the product. Easier said than done.

Throwing out the stored procedure code appeals to the architect in me ("Let’s start all over!"), but the realist in me knows that that is a thing you should never do. Given that the code that uses the stored procedures in the ASP.NET project is repetitive, I figured that using ORM would best solve this problem. I chose SubSonic over other choices like NHibernate because SubSonic wraps the stored procedure calls in objects (it does the same for our tables and other database objects). Now all the features of our database, where the business logic tragically lives, are available to us in an object-oriented way. I can refactor the existing code instead of rewriting it, and preserve the stored procedures as they are. Calling a stored proc will no longer require string-heavy usage of SqlCommand. We can use DatabaseName.SPs.StoredProcName(typed parameters).

For example, say you have your web application configured to use SubSonic. Your database connection string is named PurchasingSystem. In your actual SQL Server database, you have a stored procedure called UpdateItemList and it takes two parameters, an integer identifying the product list to update and a string that is the name of the item. (Yeah yeah, not the best example in the world, but stick with me.)

The SubSonic-generated code will let you do this:

PurchasingSystem.SPs.UpdateItemList(1, "Gears of War 2");

That is so much simpler and easier to maintain than the alternative of using ADO.NET objects.

As the kids say, ActiveRecord and scaffolding FTW.

Over the past six months, I’ve been talking about process improvement, change management, Windows Workflow, and a few other items. I talked about my role as the enterprise architect for an organization and the responsibilities of that role. Well, I made a big change a couple of weeks ago: I left EDS, an HP Company and moved back to Des Moines, IA to continue my consulting career in an independent fashion.

This is an entirely different role, encompassing more software development and architecture than the enterprise focus I had previously, but if you read some of my past posts, you’ll see that this is where I want to be. I’m working with the Microsoft stack for my current customer, and I plan to post about my experiences with this project. There are many challenges ahead.

I am the proud owner of a new HP Pavilion tz2500 tablet PC. When I first got it, I had mixed feelings. I had wanted a tablet PC for a long time, mainly because I felt it could enable some positive behaviors toward notetaking and managing the plethora of ideas and projects I have. But when I first started using it, I couldn’t figure out how it was supposed to benefit me. I knew it was good, I knew it had possibility, but I had no idea what I should be doing with it. I saw the value of the possibilities but did not have an approach to the follow-through.

Most ideas and plans work out that way, don’t they? Something swims around in your head and you know it’s awesome, but when it comes time to make it happen, it’s just not there. This happens to me all the time. In fact, that very issue is what led me to the tablet PC in the first place.

Today I felt pretty frustrated with my decision. I began to find reasons to dislike my new tablet PC. It’s too heavy. The screen is glossy. There’s too much silver. I wanted to lay the blame for returning the computer on something that was wrong with it and not me.

I relayed these concerns to a good friend and colleague, who happens to be a tablet PC owner (a different model). He showed me how to use my tablet PC. He relayed its strengths, situations where it could prove valuable, things I hadn’t thought of. He helped me understand its value and reinforced my original reasons for getting the tablet PC. He told me about some great software. His opinions and assistance allowed me to accept the computer’s shortcomings (which I admittedly knew about before I bought it) and embrace its real potential.

Every innovator needs a validator, someone who can tell you when you’re wrong and when you’re right. Someone who can help you mold an idea into something real. Someone who is honest and forthcoming with opinions. If you look back on some of history’s great innovations, you’ll see a lot of partnerships (Brin and Page, Gates and Allen) and a lot of adversarial relationships (Edison and Tesla, Microsoft and Google). That’s the balance that allows us to trumpet our accomplishments, defend our decisions, and change our approaches. It forces innovation while celebrating it.

I’m writing this post on my tablet and after finding some really good applications for it, I am in love. I look forward to taking advantage of its full potential and using it to unleash some of my most persistent and longstanding ideas.

One of the things I’ve always loved about working in this industry is the “breathing room” we give ourselves to figure things out on our own. Depending on the project or tasks, we’re able to draw on our experiences and knowledge to tackle problems of all sizes. To make things even better, we’re allowed—even expected—to acquire new knowledge at a blistering pace. And one great way to do that is to simply try.

Such as it has been the past few months as I built a tool in Visual Studio 2008, C#, and Windows Workflow. This tool, which I’ve mentioned here before, was created to serve two purposes: first, to help me keep my skills current and learn something new (namely .NET 3.0 and Windows Workflow) and second, to help simplify and automate the process of performing my weekly change management duties.

The work I’ve put into this project has resulted in a significant leap forward in my WF and .NET skills, as I had hoped and expected. The interesting side effect is that it helped me refine my change management process, showing me the areas where improvement was needed and where steps could be completely eliminated. The creation of the Windows Workflow was the catalyst for those changes. Through my technical trial and error, I was able to sort of redesign the process. From a certain point of view, the process changed to suit Windows Workflow, but the way WF is designed ensures that there’s not a tie-in between the process and the WF used to represent it.

The differences between the first iteration and the most recent iteration of the application are astounding. When I began this project, I didn’t use TDD or agile methodologies or any of that stuff of which I often sing praises. I sort of just jumped into it, learning as I went along, making mistakes and correcting them. Even in this late iteration, I’m finding things that need to be improved, bugs that need to be fixed, features that need to be added.

What struck me as the most curious product of this endeavor was the discovery that while my process became less rigid, the workflow for the process became practically ironclad. Each step in the workflow depends on the step preceding. While I had successfully decoupled the process as done by hand, I had created a monster of an inflexible beast that simply performed the steps in a predefined order, with no room for change or improvement. In other words, I had done it all wrong. Once I reached a point where I realized that the RFC documents absolutely had to be in the source folder before I could start working on the review because my application required it, I completely understood that I had shifted the inflexibility from my work to my workflow.

Thus, even as I feel like I’m near completion, I know that I have more work to do. The plus side is I have a working product that does what I need it to do, albeit inflexibly and unable to handle exceptions. That’s for future iterations, work that I am quite looking forward to.

I decided to spend some quality time working on the Windows Workflow application I wrote to support the document workflow that is such a crucial part of the weekly Technical Review Board that I run for change management. The first couple of iterations of the application were pretty simple: it would take an Excel document as an input, along with some fields set by the user (date of the agenda, which RFCs to review [by number]), and then output an agenda along with a formatted Excel document to make reviewing the RFCs a little easier.

But there were still too many tasks done by hand. I knew more could be automated: extracting the RFC detail from the list into the agenda, creating the PDF packet, emailing it to everyone. Ideally, the application would have only one human step: actually reviewing the RFCs. So it would go through the process of bringing documents together, pause while I do my thing, and then resume with more creation and sharing of information.

I’m not quite there yet. It’s a side project so I can’t put too much time into it, but I do have a rough design in mind and, like so many little prototype one-off applications, this one will grow into an essential tool for this role.

And now for some interesting technical tidbits. I rewrote the Office integration piece to make it more stable and less resource-intensive, so I implemented the Excel and Word automators as Singletons, using a pretty simple IAutomator interface. Since I had started working on the Excel automator before the Word one, it had grown into some pretty gnarly code, while the Word automator was clean and well-designed, the product of experience. I stripped out a lot of unnecessary code, implemented the interface, and ensured only one instance of the Office COM objects were instantiated. I also added much-needed Marshaling code to release the COM objects when the whole thing was done. It’s pretty standard stuff as you move an app from simple prototype into more useful (and shareable) tool.

One thing that caught me up though was that the workflow kept spawning two copies of Excel. I couldn’t figure out why. I had thought that the Singleton pattern would ensure that wouldn’t happen, but what that ended up doing was skewing my attention from the root of the problem. I finally discovered that I stupidly called the Initialize() method twice, spawning that extra copy of Excel. I couldn’t find the bug because I thought I was smarter than that. As tools get more powerful and languages add more features, we easily get caught up in that stuff, forgetting the basic principles.

My computer math teacher in high school taught me skills that I still use today. One of those is the pencil test. With the pencil test, you literally use a pencil to point at each line of code on your screen, reading every bit of code one line at a time until you find an error. It made for some interesting debugging, but in those days of GW-BASIC, it was all we had. And that “pencil test” is what helped me find my silly Excel COM bug today.

The joy—and pain—of software development can only be summed up so simply.

Years ago, when I first started working in the IT business at a small electric company in Texas, I had a coworker named Jim. Jim was in his 60s and had been an electrical engineer all his life, which in 1994 added up to about 40 years. He was enormously respected for his understandably dizzying knowledge of electrical engineering, especially when it involved transmission lines and substations.

My interaction with Jim was a support role. The electric company had computers on every desk, loaded with Microsoft Office and AutoCAD for the engineers. Jim would try to figure out how to solve his own IT support issues, and it usually resulted in things getting worse. For example, one day he called me and said that his mouse was moving around on his screen too fast. I sat down at his desk and instantly realized that his mouse pointer acceleration was set to the maximum. I guess he had been playing around with it and set it too high. Typical engineer!

Jim used the same greeting with everyone he saw during the day: “How’s your day going?” It always resulted in the same canned replies, like “fine” and “great.” I didn’t realize the philosophical implications of Jim’s question until much later: what am I doing and what I have accomplished so far.

Today I have evaluated 11 change requests for technical errors, changed the enterprise architecture diagram for a solution assessment, and fixed a bug in the C# code for my workflow application. That’s what I’ve accomplished so far.

But what am I doing? How is the rest of my day going? How can I ensure I’m giving my customer a maximum return on their investment? What can I do to ensure that when I get home, I can tell my fiancee that I’ve had a good day?

The answer has two parts: first, how can I track what I’m doing, and second, how can I know when it’s done. To-do lists, notes in OneNote, task list in Outlook, sticky notes on my monitor, Follow Up tags on my emails, or a mental list just a few of the many ways people track the ever-expanding list of Things to Do. I’ve tried them all. I settled on using different tools for each job. I use Excel to track the change requests I’m reviewing. I use Outlook to manage the tasks associated with following up with change builders. I use OneNote to track the lifecycle of certain documents that undergo a lot of changes from meeting to meeting.

In information technology, the management of Things to Do has wide-reaching influences and often requires a substantial investment in tools and people. Everything from the business processes to the schedule to the project manager to the people doing the work has to be meticulously tracked, verified, and managed. This is one of the cornerstones of good IT governance.

Hats off to you, Jim, wherever you are now.

I love coding. I always have, and I think I always will. When I’m writing code, I’m having fun, I’m satisfying my intellectual curiosity, I’m creating something, I’m accomplishing a goal, and I’m getting instant gratification. I just love to code. The thing is, I don’t get to do much of it anymore. As often happens to developers in IT, I’ve moved from the code-producing job into the application-management job. My responsibilities moved out of the of the design/develop phase of the lifecycle and into the deployment/management phase.

You can’t keep a good coder down, so I find ways to inject my true passion into my current role. I use code to solve problems that are exposed by my job. For example, I created a Windows Workflow application to help me manage the technical review process for change requests, which are my business responsibility. Rather than have a coding role mandated by the needs of a development project, I code tools that help me—and the people I work with—get things done. It’s not any more or less noble than any other coding job; it’s just, well, different.

And because I will always be a coder at heart, I’m looking for ways to extend my knowledge of software development into my role in the PMO, and future roles that I might drop into in the future. So I’m reading a book called Code Leader by Patrick Cauldwell, which came recommended by Scott Hanselman (who wrote the foreword), and quite luckily, I won in a raffle at the Lansing Day of .NET last month. I had been looking for a book that summarized the modern responsibilities of a software development manager so it was quite fortuitous that the book dropped into my lap. It covers a variety of topics that are the hot-button issues of today, like continuous integration, test driven development, dependency management, and Model-View-Presenter. I’ve been pretty pleased with it so far. I had never really understood continuous integration until I read about it in this book. Discussions about CI always leaned toward the details of CruiseControl rather than the theory behind CI.

If I can be a strong development manager and combine that with my IT management skills, then I can achieve my goal of quality software that works. Maybe that should be capitalized. Quality Software That Works. QSTW shouldn’t be a dream. QSTW shouldn’t be a product of processes and meetings. It should just be. And the path to QSTW is established in books like Code Leader and Code Complete.

I am always looking for ways to improve my own coding and the projects under my watch. Keeping up with the changes and new technologies in the software development world is a constant challenge. But that’s a topic for another post.