Geeks With Blogs
Rotten Code it can always work better - but at least it should work
Last week I was listening to Jack Greenfield on .Net Rocks! discussing software factories.

Jack views software factories beyond mere code reuse, but extending to controls, tools, etc. He states that he believes, and I agree with him on this, that developers are hell-bent-for-leather to build everything from scratch every time, and that we have to learn to use tools to free us to build bigger and better things instead of re-inventing the wheel every time.

This caused me to think about my own approach to development. I’m all about code reuse. I think it would be stupid for me to write code to perform the same action over and over, and if I can borrow a snippet from someone else, that works too. They can borrow mine, it doesn’t matter.

And I agree with the idea of using tools to move programming ahead. I know that despite some people viewing VB 6 as though it was a ‘toy’ language, it wasn’t a toy for many common business applications. And given my views on ‘Rotten Code’ that works, I would argue that the VB language and Visual Studio IDE was a huge factor in creating a massive ‘business tool’ software industry. Literally, millions of programmers and thousands upon thousands of business applications – many still in use today – were created because of the speed and ease of Visual Basic 6. In fact, some of this was lost with the introduction of VB.NET, which is sort of a Franken-language between Java, C# and Visual Basic. Ah, but I digress.

At any rate, given my inclination to support the concept of software factories, and pre-built components are sort of a piece of that puzzle, why then, I wondered, do I personally dislike so many pre-built components and controls? As a rule, I avoid them. For example, I haven’t really embraced the much-hyped and discussed Microsoft Ajax.net controls because I had already written code that accomplishes what their framework does, and I didn’t need their JavaScript libraries or any of their additional code. The only thing I noted in their framework was the use of JSON, where I was using XML in some cases and JSON in others to pass parameters asynchronously. And I thought about this – I really don’t think it’s because I think I’m a great coder, or that my code is really any different or better than Microsoft’s. It’s not that I think using Microsoft’s code means slower development. It doesn’t have anything to do with Microsoft’s code. It’s my aversion to all such controls, to approach them skeptically and avoid them unless they absolutely offer something of measurable quality.

The reality is, I think, that most pre-built components just don’t…work well. There has been a vendor market for pre-built components for a long, long time, and occasionally I’ve found one that worked so well I couldn’t see any reason to write the code myself. But my criteria for ‘work well’ are usually limited to:

- small footprint, both in processing and code implementation
- can be removed or tweaked with little effort
- requires very few parameters or properties, and those values are not complex
- does not require major installs, libraries, app servers, etc.

You get the idea; I want a component that fits quietly and snugly into my code, just as if I’d written it. It should work effeciently and you should almost not even know if it’s there. Too many times I’ve been given a project, taking over maintenance on an existing app where the previous coder used some extensive controls, and the frustration of spending hours or days just to install everything to DEBUG is ridiculous. Sometimes the control requires so many parameters to be set, or apps or libraries with custom classes – and usually there is no documentation to list said parameters – that I can’t help but wonder why it wasn’t just written from scratch, because now I have to try and fix an internal error in a product that I don’t have access to the code for. That, and the fact that the functionality the component added was nothing more than a new date-time picker.

The basic issue, I guess, is often the pre-built component adds so much overhead and work that it no longer is saving time or making the application actually better. I can recall one assignment where I was tasked with building a web app to deliver pre-built reports, and also to tie into a (non-Microsoft) analytics reporting engine. The .NET code provided by the vendor also required – get this – TomCat to be installed on the server. It didn’t matter that we were already using an IBM application server; the .NET tools required TomCat, and wouldn’t work unless it was installed. No way to quickly point it to a different app server. That’s just amateurish, and quite frankly, not acceptable. If you are going to hand me a .NET component that I can plug into, a component which I or my company paid for, then it should work so well that I would never dream of writing my own, better code. Which, in this case, I did. Adding TomCat to our production servers was not an option, and to do so would have just added more layers of unnecessary complexity. I chucked the pre-built .NET component and built one that worked faster and sleeker. Again, I didn’t want to. I had to because of the weakness of the component.

So, as for software factories, I think it’s a great idea. But first, we’ve got to start by creating better tools and components to hand off to each other. Posted on Wednesday, March 21, 2007 5:01 PM | Back to top


Comments on this post: Software Factories, A Great Idea and I'm Not Ready

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Marcus Shockley | Powered by: GeeksWithBlogs.net