The goals of your development team is centralized around producing a feature-rich, secure, scalable, robust suite of software that can be sold out of the box to customers.

In order to accomplish that task development teams need to restructure how they look at projects. I’m proposing a new term called Code Longevity. Code Longevity means thinking about software development in terms of fluidness; how easy is the source code to change, adapt, and be repaired over time. Code Longevity requires code modularity, code documentation, standardization of code styles, and a flexible architecture. Successful software is not static, it is a living entity that grows and evolves through time

The software management team must anticipate the future applications of the product and realizing that building generic interfaces will allow the software to adapt to unknown directions the software may evolve. No software evolution cycles can be perfectly predicted due to outside variables therefore the software must be designed in the general case even though it may take more time to initially develop. After the time has been taken to create the general case of the software then the evolutionary line can make sharper, more agile changes in direction as there is minimal development necessary.

By modularizing our approach to software and creating a core asset collection of core components we are in a sense productizing our software source code. The core assets now act as component products, where developers can create extremely advanced application software without knowledge of the inner workings of the core assets. A developer can think about implementation and logic flow for their particular development goal rather than have to think about building the supporting tools (APIs and software libraries) that will make the goal feasible.

This is a philosophical discussion. In fact, switching barriers are one of the points that are argued during the open vs. closed information debate. Open-ness encourages trial of products and services while closed-ness encourages brand loyalty. As developers and entrepreneurs we have to look at out our philosophical view on information (our software, products, and services) and come to resolution with our business goals.

I was inspired by a comment I got on my post about Microsoft, Linux, and being professionally pidgeon-holed. The commenter brought up the point of “lock-in” when using Microsoft.

I agreed, and responded that people, like myself, are willing to be “locked-in” if the product or service provides some value, real or imagined. For example, look at the recent iPhone distaste about the AT&T contract. Look at the iPod and DRM. Look at your car and any modifications you purchase. Look at your gym membership. Though they create artificial ways of locking you in, all those products and services continue to flourish!
Corporations look to lock you in and create switching barriers to keep you loyal. They do it with termination fees (such as gym memberships), with investments in proprietary equipment (such as digital gadgets), by holding your data hostage (such as iPod/iTunes).

As entrepreneurs and developers we need to make these decisions all the time, do we use proprietary protocols or open standards? Do we use a third party proprietary software because it’s cheaper and faster? Do we follow our philosophical views and stay away from closed software and standards? Do we make it difficult for customers to switch?

Switching barriers are an important part of the competitive landscape. Look for barriers that you can create and figure out how to break down the barriers of your competition. Think hard when developing your business or your software, what barriers are you willing to create? What barriers will your customers tolerate?

A developer, no matter how skilled, is dependent on the tools at his disposal. There are numerous free tools to aid in .Net development; from source control to debugging to documentation and profiling. Here, I’ve compiled a complete list of tools that I’ve used for years that cover the entire development lifecycle.

C# and .Net are a powerful language and platform for developing software. The high levels of abstraction, garbage collection, architecture, and runtime provide an amazing platform for writing high quality software. It’s a great start, but it’s not enough.

In the end, quality software comes down to developer skill and organization. This article will provide some links to free tools that every .Net developer should have on hand in order to write high quality software. If you don’t know what a tool does, I encourage you to explore it, you may learn something new about source control, test driven development, profiling, continual integration, or debugging that you didn’t know before.

What follows is a best of breed toolkit that I use personally and professionally almost every day. All the tools are freely available for download online (with the exception of the full Visual Studio 2005 suite).

IDE
Visual Studio 2005(Not Free) – In my opinion it’s the best IDE in the world. Supports many languages, integrated web server, code completion, refactoring tools, debugger, etc. etc. etc… it’s a pleasure to use. Just make sure you have a quick system, all the fancy features can take come CPU cycles and memory.

Visual Studio 2005 Express Edition (Free) – If you are getting started you don’t need to buy the fully Visual Studio package yet, Visual Studio 2005 Express Edition is free and let’s you do just about everything you can do in the full package.

Profiling Tools
CLR Profiler for .Net 2.0 – “The CLR Profiler includes a number of very useful views of the allocation profile, including a histogram of allocated types, allocation and call graphs, a time line showing GCs of various generations and the resulting state of the managed heap after those collections, and a call tree showing per-method allocations and assembly loads.”

Debugging
Windbg – This is the debugger for Windows from Microsoft. It’s command line driven, difficult to use, and give you exposure to everything. And, there are symbols and tools for .Net. Some tutorials to get started: .Net Framework Source Code and Debugging and A Windbg Tutorial.

Code Analysis Tools
Reflector for .Net- “Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL.” This one is especially helpful for getting insight into third party .Net libraries that you may be using in your projects.

DevMetrics by Anticipating Minds- This is a closed source but free tool for running basic analysis on your .Net projects. The application installs as a plugin to the Visual Studio environment as well as provides a console utility. The tool will provide you a breakdown of lines of code, cyclomatic complexity, and other metrics by solution, project, file, and object.

Unit Testing Tools
NUnit- NUnit is a tool for developing, maintaining, and running unit tests. By using NUnit to write test procedures (say, versus a console application) you can maintain tests for regression testing, easily execute all or a subset of tests, and get reports of results. Take a day to read the short documentation, I found it fit very well into my development pattern.

Documentation Tools
NDoc Code Documentation Generator for .Net- NDoc is a great tool for developing documentation files in various formats including HTML Help. If you are familiar with .Net development you’ll know about the meta tags that are available when commenting code. The Microsoft compiler provides a flag to execute all of your in-code comments into an XML file. NDoc takes this XML file and makes it a user friendly readable and distributable format. By thoroughly documenting your code (as you should) NDoc will compile a valuable documentation file for future developers, testers, and other team members.

Compliance Tools
FxCop- “FxCop is a code analysis tool that checks .NET managed code assemblies for conformance to the Microsoft .NET Framework Design Guidelines.” FxCop is a very in depth tool for analyzing source code for compliance. It was built by Microsoft for internal use to ensure uniform coding styles and standards across the company.

Build Tools
nAnt- “NAnt is a free .NET build tool.” nAnt provides the ability to automate the complete build process. From integrating with source control for branching or tagging. To building the project. To copying files. To version control. Use nAnt to ensure all the steps to bring your software from code to test to delivery are consistent and complete.

Contiuous Integration Tools
CruiseControl- “CruiseControl is a framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various source control tools. A web interface is provided to view the details of the current and previous builds.” Use CruiseControl especially if you have multiple developers checking in changes to ensure that your projects build successfully and pass unit tests all the time.

Source Control Tools
Subversion and TortoiseSVN- Subversion is an open source CVS replacement that many in the community find superior. TortoiseSVN is a great Windows client that provides Windows Explorer integration for managing your repositories. I’ve used SVN professionally and recommend it.

CVS and TortoiseCVS- CVS is a popular and free source control system. TortoiseCVS provides Windows Explorer integration for repository management. This is the system I use at home and you’ll find most projects on the web use CVS as well.

First, let me give some context for when and why I wrote this article. This is an article I wrote in early 2001 as I began to take over executive responsibilities in a small software company. The startup was comprised of three developers where there was much turnover of contractors and employees within software development for team member four and beyond.

As a primary developer/architect as well as a team leader and company partner I developed a strategy that I called productized components. This is a strategy I used to manage scalability of a churning team while maintaining security and an ability for new developers to rapidly understand existing software resources. It also provided a clear delineation for us to find new revenue streams by selling components of our product suite to other development groups and IT departments.

This article is raw, as I’ve left it basically unedited from its initial draft writing six years ago. Please excuse what I consider poor writing and overlook that for some tidbits of ideas that I think are valid.

What is a component product?

The term component product refers to one or more binary components that perform a specific task or related set of tasks. This is a discreet, black box object that is generic enough to be moved without modification from one application to another. The product part of this concept means that after completion, the component will rarely, if ever, require viewing or changing of its internals.

A fully productized component is not just the compiled binary. It also includes full documentation of the interface and any applicable information about how it works internally. Documentation includes proper use, optimization techniques, a description of the external interface, and examples.

Component products (or any component for that matter) must be perfect. This means the control must handle all error conditions, must be optimized to the fullest, all behavior must be known and consistent, all return codes must be accurate, it must have no bugs.

While this article does not discuss source level componentization, all developers in good practice should develop in a componentized, object oriented manner with regard for design patterns. Source level components should be used to compose binary level product components.

Why companies should develop component products internally?

This system also provides security and scalability to your software department in that contract workers do not have an inside look at the most important part of the software. Instead all they have access to are exposed interfaces of the core-productized components. The core software remains protected from theft or change. Only the binary components will be accessible to parties under lower levels of trust. Couple this with a binary licensing system and your core technology remains secure. If you binaries are stolen it will only work if your license is taken, which means your corporate name and licensing information remains with the binary.

How to build a productized component

For a component to be successful there are certain requirements that must be met:

1. Advanced planning
2. Ability to stand alone
3. Proper documentation
4. Consistent behavior
5. Virtually no bugs!

Benefits of components:

1. Reuse of legacy code
2. Internal security
3. Manageability
4. Upgradability

Core components, and actually any component for that matter, must be perfect. This means the control must handle all error conditions, must be optimized to the fullest, all behavior must be known and documented, all return codes must be accurate, it must have no bugs.This seems like a tall order, and of course it is rare that software of any sort of true magnitude has no bugs. But in the componentized model the components must be small enough that they can be developed so they are near perfect.

This is a must because components are used in binary form; other developers cannot debug them and fix them. If a developer is using a series of components to create something bigger, it is expected and a must that if any bugs or inefficiencies arise it must be a given to the developer that the bug occurs in the code integrating the components and not the components themselves.

If a component is being implemented as the documentation describes then it should behave consistently, without hiccup, without surprise. If the component does contain an error then it is a nightmare for the developer integrating the component. It is difficult to determine that the component is at fault because of the trust given to the component and the mindset of the developer that black box controls should work, period.

It is important to spend most time debugging, testing, and assuring that components behave consistently and as documented. There must be no surprises. If a component is written poorly it’s a given that the application using the component will be poor.

I cannot repeat this enough: components, especially core, productized components, must be perfect because it is difficult for an integrating developer to identify the problem if it is in the component and not it’s implementation. There is no source available so the only recourse for the integrating developer is inefficient: to contact the supporter/developer of the component for cooperative debugging.

So test, test, and test again. Have multiple developers outside of the group who developed the component to review it, have them look for optimizations, bugs, logic flaws, memory leaks, and anything else that’s worth fixing. Sometimes new eyes can see the obvious things that the original developers eyes are used to seeing. Many times the reviewing developers will have different and more efficient approaches due to more experience or more knowledge of an API or something of that sort. It is very important to get many eyes on the code to look for improvement points and to always test, test, test after any change has been made.

What type of programmers build and use productized components

When it comes to the management of manpower productized components can provide a much clearer delineation of work than otherwise possible. With a productized component approach there are at least two categories of workers. First, the high skilled personnel who design, implement, and maintain the core productized components. The second category is the lower skilled labor that can use the productized components to build additions to the application.

The cons of productized components

Productized components take a longer to implement and must be developed by higher skilled developers. While the completion of a task can be done by a certain level programmer the ability to architect a generic implementation in the form of a reusable component requires a skilled, experienced developer.

The process of developing the component also takes more time than simply completing the task. The component must be thoroughly researched, be well implemented, and be tested even more than a solution. A component must be perfect for all cases and not just for the case of the specific implementation.

I’ve started a new project… in fact I’m coming back to an old project in a new way. Computing intelligence… whether its’ artificial, business, or minimal intelligence.

Early in my self education the concept of AI and passing the Turing test were high in my mind. I prototyped an application called Lisa which would perform basic chat functions on a limited knowledge set that was given a priori. Lisa could not assimilate data auto-magically.

My goal is to shoot high, to create a unified model of human memory that can have set math performed on it (union, intersection, etc.), has levels of degredation for physical memory limitations, has temporal knowledge, and that can be expanded.

This time will hopefully be different than the last, this time my significant other, Moniece Gothard, is collaborating with me. She is a psychology graduate with an emphasis in bio-psychology. She’s incredibly smart and insightful (not just bias talking here) and has provided incredible insights and collaboration with me. Thanks, babe!

This memory structure layer is simply a storage mechanism with optional additional processing to move “memories” between temporal storage layers, contextual layers, and archival layers.

In the future, a processing and interpreter can be built to suit needs of data analysis (pattern recognition, forecasting, etc), business intelligence, and human-like interaction.

While the aim is a human-like interaction, I hope that if I fall short there will be at least a strong general purpose memory mechanism that will be powerful for all intelligent computing applications.

So, the high level details on the memory structure implementation. The base of it is an n-linked fuzzy list using a subject, predicate, object, degree quadruple to define each link. These structures can be queried for different data views, have set math performed on them, and ultimately be used for temporal and static storage… with the assistance of a memory processor that will handle filtering, archival, deletion, and summarization of data to variable degrees.

The hope is that this general purpose storage mechanism will conceptually work in the general case and be able to provide more querying or data analysis information such as pattern recognition, forcasting, answering queries, and finding both obvious and non-obvious relationships.

Keep tuned for more information, and if you have interest in collaborating on the project, leave a comment or shoot me an email.

 http://www.lowesoftware.com