I was listening to Scott Hanselman's podcast #158 (http://www.hanselminutes.com/default.aspx?showID=176), which was an interview with Joel Spolsky, founder of Fog Creek Software.

A couple of take aways ... first, Joel Spolsky is a wickedly smart dude.  BTW, this is the same "Joel" that I was picking on a few days ago in my "Kevin On Hiring" blog post.  I still stand by the things I said in that post, but it makes me nervous when I start picking a fight with someone of Joel's intellect.

Second, stackoverflow.com is pretty cool.  I've run across this site a few times while Googling for stuff, but now I'm starting to go directly to stackoverflow.com for searches on programming-related questions.

I've never been a huge fan of Google.  I use it, of course, and I get useful results from it from time to time.  But a lot of times, man is it frustrating.  It isn't optimized for searching for programming-related questions.  That's the problem stackoverflow.com was created to solve.  It's community-oriented, so users can vote on the best answers to questions, and if you participate in answering questions, you can build up "reputation" points.  Like I said, it's pretty cool.  To learn more about the motiviation behind stackoverflow, listen to the podcast above.  Then, give stackoverflow.com a whirl.

Today I attended a Microsoft "Big Event" in Denver that covered Visual Studio Team System.

A lot the content was already familiar to me, but I did appreciate Rob Bagby's demo of Visual Studio Database Edition.  I've known about it, but haven't used it, and wasn't sure if it was something that would help me or not.

There is some good stuff in there, such as database unit tests and nice tooling for generating sample data to test against.  Overall, however, I don't think Database Edition is really geared towards the way I work.  Let me explain.

For nearly all of my 20 year career, I've worked in small startup companies developing database oriented applications.  I've developed two defect tracking systems (PVCS Tracker and TeamTrack), a build / continuous integration system (BuildBeat), and currently, an automated branching & merging system (MergeMagician).  Although the development language changed over the years, all of them used back-end relational databases and some sort of ORM mapping layer.  In all cases, the database was created by the user of the software (none of them were SaaS solutions), using an administrative component and/or wizard that was embedded in the system itself.  Having created the database, the system would then populate it with data as the user used the system (submitted defects, ran builds, etc.)

In this mode of operation, information about the database schema, starts in the application, usually in the form of an XML metadata file that is associated with the ORM mapping layer.  Using this metadata, the application dynamically generates SQL statements and issues them to the database.  This seems a very natural way to work, and because it is so ingrained in how I've worked, it's hard for me to envision doing it any other way.  It turns out, however, that in IT-oriented environments, that database in many cases pre-dates the application under development and already exists.  Developer's in these cases need to transform or import the database schema into a form that programmers can work with.  As the code is modified and deployed, you run into synchronization problems with keeping your code, your development database, and your production database aligned with each other.  This is one of the main areas the Database Edition targets.

Using the database that already exists (once again, an exasperating concept to me), you import the schema with Database Edition and you get a bunch of .SQL file injected into your project.  That means that "the truth about your schema" can now exist independent of the actual database instance.  Since they are regular text files, you can check them into source code, version them, and do all the same sorts of things that you would do with ordinary source code.  You can also now create new database instances, using the single schema truth (your .SQL files in your project).  That makes perfect sense, and once again, the fact you would do anything other than 1) Create file(s) that describe the schema you want, and then 2) Create a database instance using that description, makes it difficult for me to see this concept as revolutionary.  But apparently it is to a lot of people.

The problem for me, however, is that I never work directly with .SQL files.  I always work with a more descriptive file format (usually XML) that not only holds the information that is needed by the database to initialize the schema, but I also store extra metadata in the file that assists in other areas, such as generating documentation and generating code.  The descriptive XML file works in conjunction with the ORM layer and/or code generator so that you get what you want.  Microsoft recognizes this way of working with two technologies, LINQ to SQL, which uses a .DBML file format, and Entity Framework, which uses .EDMX, both of which are XML based.  I have my own ORM mapping layer, which also uses an XML-based metadata file.  The SQL statements are either dynamically created at runtime, or they are code generated.  I think most ORM tools on the market work this way.  It insulates you from working directly with .SQL files.  This is why I have a hard time seeing how Database Edition would be all that useful to me.

I tried to explain these thoughts to Rob Bagby, who, not surprisingly, didn't agree with me.  He asserted that storing the "schema truth" in .SQL files was the right way to do things because "SQL is the industry standard."  For me and my way of working, I still don't buy it.  SQL is a bad file format for me for the following reasons:

* It's hard to parse, and thus hard to manipulate with external tools.  With an XML file format, I can create an XSD and then code generate a data binding layer to read in the file and process it however I want.  With SQL, I have to break into heavy duty lex/yacc and start dealing with language grammars.  I'm sure there are a lot of SQL parsers out there I could use, but it's going to be more work for me.
* It doesn't store enough information.  I want something that not only stores information needed to create the schema, but extra metadata, such as prefixes, name transformations, namespaces, etc., that will feed into my code generator.
* It's not extensible.
* If I target multiple databases (such a MySQL and Oracle), using SQL is dangerous because different databases use slightly different syntaxes.  With an XML file format, I can make different transformations to handle other database types.

For me, SQL is an intermediate file format, not an input file format.  People who work the way I do, are more in need of a tool that will synchronize their XML metadata file (.DBML, .EDMX, or other) with the database schema.  I know a lot of people that are struggling with this very issue.

I've started on an open source project to do this sort of thing.  It's called DbmlManager, and it's available at http://www.codeplex.com/dbmlmanager.  It's not very far along however, but if anyone wants to work on it with me, let me know.

I was at the bookstore today and I was flipping through Joel On Software when I came across the chapter on hiring.  As is typical of other business books, it promoted a "hire the best" philosophy.  I've pondered this notion over the years, and wanted to share my thoughts.

Let me first say that I agree with the underlying philosophy of the advice, that being that a small number of highly-motivated, talented people can outperform an army of mediocre individuals.  However, there are several aspects of the "hire the best" mantra that have always bothered me.

First, it has unfortunately become a tired old management cliche.  Of course everybody says they hire the best.  Who would ever boast about hiring the worst?  And who would ever want to work for a company that brags about hiring the worst?  But saying you hire the best, and actually hiring the best are two very different things.

Second, it's a bit absolutist.  In my mind, if there are 17 million programmers in the world, then "hire the best" means 1 person has a job and the other 16,999,999 people are unemployed.  That's obviously impractical, making the advice at the most general level non-actionable.  I hate non-actionable advice.

Third, there really is no such thing as "the best".  There are a variety of factors that make up a good associate - raw intelligence, communication skills, people skills, work ethic, etc.  Every potential employee will have a unique mix of these aspects ... no one is perfect at everything.

Fourth, what does it say about me?  Am I the best?  I do the very best I can to "sharpen the saw" of my personal skill set.  I read programming books and magazines, self-teach myself new technologies, read blogs, and attend all manner of workshops, user groups, and code camps.  I feel like I'm at the top of my game, and the best programmer that I've ever been.  But am I the absolute best?  In a world filled with so much talent, it would be very conceited of me to make such a claim.

Lastly, what do you do if you live in a small city like I do that isn't the epicenter of the technological world?  Should I move to San Jose, CA or Redmond, WA, where the per-capita talent may be higher than where I live?  And how can I compete as a small software company if all the other larger software companies have already gobbled up the best talent?

So here's my take on it.  I don't think you need to move to California or Washington.  I think there are plenty of smart people all around ... you just have to find them.  I think you should hiring the smartest people you can find, invest in them to help them be the best they can be, and encourage them to fanatically acquire domain knowledge.

The latter two points above seem to be glossed over too quickly by "hire the best" aficionados.  Yes, raw talent is a very important aspect, but I think great programmers are born over time, not stamped out at a factory.  And I want people who care intensely about what they're doing and want to learn everything they possibly can about their domain.  There are just too many people in the world that want to punch a clock and pick up a paycheck.  Give me people with passion.

Which brings me to my closing thought ... leadership.  You can have the best people in the world, but without great leadership they won't accomplish much.  And in a small software company, leadership pretty much comes down to one thing ... YOU.

I've been using T4 to do some code generation in Visual Studio 2008.  I shot a 4-part screencast series that describes the entire process.

In the videos, I talk about two open source projects, both available on CodePlex. 

The T4 Toolbox is available at www.codeplex.com/t4toolbox.
XmlGen# is available at www.codeplex.com/xmlgensharp.

Videos
Part 1 - Creating XML Data Bindings using XmlGen#
Part 2 - The XML data file and T4 code generation harness
Part 3 - The T4 template
Part 4 - Using TemplateEx to manage whitespace

Back in the early days of my career, it seems you could just pick an idea, do it, and then sell it.  Times are different now.  How do you navigate the entrepreneurial waters in this era?

Getting back to my first blog entry in this series, I certainly agree with my sales and marketing friends that disconnecting from the world for a long period of time while attempting to write a perfect product is dangerous.  On the other hand, I've had a lot of challenges trying to utilize the personalized, one-on-one interview technique that they suggest.  Some challenges I run into include:

1.       It's a process that doesn't fit well with my core personality.

2.       Identifying good people to interview is hard.  For me, interviewing software developers doesn't seem to be good enough.  I need people with expertise in ALM to get valuable feedback about the ideas I have.

3.       Despite the assurances of my sales and marketing friends, no common pattern of need has emerged as I've done these interviews over the past few years.

4.       It's an emotional rollercoaster.  If I talk to someone that gets what I'm talking about, I'm excited and ready to start cranking out code.  If they don't get it, I get discouraged and wonder if it's really a very good idea or not.  I suspect that I might have thrown in the towel on some good ideas because the handful of people I talked to about it didn't get it.

5.       You have to conduct a large number of interviews to get any statistically valid data.

6.       Most people don't give you actionable feedback.  Most people just say something very generic like "That sounds interesting."

So what do you do?  I have a process in mind that I think, based on observations of other successful startup companies, will work.  To describe the process, I'll start with an analogy.

Suppose you're an adventure tour operator specializing in shark petting.  You want your tourists to see as many sharks as possible.  So how do you go about bringing the sharks and the tourists together?

In one approach, you start with a detailed map of the ocean floor.  You conduct detailed data mining on every shark that's ever been caught by a fisherman.  You then dive down into the ocean with a remote controlled submarine to make contact with each individual shark.  When you find a shark, you tag them with a tracking device.  Then, using the world's most advanced radar system, you map the movement of each shark, feeding all of that data into another data mining program.  From here, you discover where the highest concentrations of sharks live.  You take your tourists to that location, dispatch each tourist in their very own submarine, and chase the shark down to get a glimpse of it.

Pretty complicated approach, right?  It's hard to do because the ocean is so big, and the sharks are too few.  Let's look at a simpler approach that's more doable.

Armed with some general knowledge of shark migratory patterns, you drop anchor in a location where you think you have a reasonable chance of attracting some sharks.  You then drop chum in the water to get the sharks to come to you.

And that's how I think you have to do things.  The location represents your product idea.  The sharks represent your potential customers.  The chum represents activities that you do that will get potential customers to come to your web site and take a look.

The key is to write code and chum at the same time.  If you only write code, then when the product is released you'll be dropping it into a world that is unprepared for it.  One of the main reasons for chumming isn't just that it provides research data, but that it builds buzz and momentum so that the market is primed and ready for the product.

How do you chum?  Try these things ...

·         Get the product web site up and running with software that supports groups and forums, so you can communicate with visitors.

·         Start an early access program.  Some information should be available to everyone, but  detailed product information and downloads should require registration.

·         Contact everyone on your Facebook friends list and your LinkedIn network to let them know about the product web site and early access program.  Invite people to join the early access program.

·         Write white papers and make them available on your own web site and other applicable web sites, if possible.

·         Start your search engine optimization efforts prior to product launch.

·         Start your own blog.  Don't just blog directly about the product, but also blog about tangentially-related topics.

·         Visit other people's blogs and post comments that link back to your web site.

·         Get other people to blog about the product.

·         For people registered with the early access program, publish early mockups and screencasts about the product.  I'm using Balsamiq Mockups for this (www.balsamiq.com).  Create a forum on the web site for people to provide feedback.

·         Start an open source project that provides functionality that is tangentially-related to the product you're working on.  If such open source projects already exist, become a contributor to those projects.

·         Join mailing lists or Internet groups that serve users with similar needs or desires to your product.  If none exist, create your own.

·         Use agile software development practices to get incremental beta releases in the hands of beta testers early.  Try to get something useful out fast.

 

All of these things are great, after you've settled on a product idea you want to pursue.  But that still leads back to the original question I posed, how do you decide upon the idea itself?  My advice is stop looking for a perfect idea.  It doesn't exist.  Pick a problem area that you've personally experienced.  If it's a problem for you, it's a problem for other people also.  Pick something you're passionate about.  Pick something unique.  Create.  Innovate.  If the product space you're going into already exists, then try to figure out at least two or three things that will make your product unique from all others.

Then, just do it.

After Software Edge was sold, I worked for INTERSOLV for about a year, and started my second company, TeamShare, in early 1996.  This was in the very early stages of the Internet taking off, so like a lot of people, I was thinking about how to do something useful in the new era.

I went back to my roots with defect tracking, which by now I had built up nearly four years of domain expertise in.  Being shy and introverted, I didn't do any customer interviews at all.  I simply drew upon the customer experience I already had from building DCS.

Based on that experience, I thought a browser-based interface would solve three problems.  First, it would be easier for distributed teams to work together, and I knew from DCS that there were lots of customers that had distributed, or extended teams.  Second, it would eliminate client installs, which caused a lot of problems with DCS when we did upgrades from one version to the next.  Basically everyone had to do the upgrade at the same time, and people using an old client version couldn't talk to the new server.  It was hard for people to coordinate their upgrades.  Third, there was a technical problem with the way DCS handled its user inbox, which was used for defect notifications.  If someone hadn't logged in for a long time, we had to synchronize changes down to the desktop.  It was a slow process and made a lot of customers angry.  I figured a browser-based interface would eliminate the need for this desktop synchronization.

I wasn't sure if making it web-based would be enough of a differentiator from PVCS Tracker, so I looked for a couple of other features I could add to make TeamTrack better than PVCS Tracker.

DCS had a lot of built-in reports, which customers liked.  We also had the concept of projects, which allowed customers to delineate their development groups from each other.  The reports worked on a per-project basis.  This worked well at the tactical level, but as upper management started to use the system, they complained about not being able to see the big picture.  There was no way to run reports across multiple projects to get a consolidated, high-level view.  I remember Bob Pinna telling me, "Kevin, people want cross-project reports.  If you can just crack that nut, we'll have it made."

To deliver this feature, I decided to implement hierarchical projects.  I figured if projects could be arranged hierarchically, then reports could be run recursively across multiple projects, and customers would have what they'd been asking for.

The other need I decided to tackle was required fields.  What customers said to us was, "The reports you have in DCS is great, but they're useless to me.  No one ever fills in the fields they're supposed to, so we don't have good data to use in the reports."  So I thought a lot about how to have a good implementation of required fields.  I realized that it wasn't just about getting the required fields filled in, but they had to be filled in at the right time.  So I decided to build into TeamTrack the concept of workflow, consisting of states and transitions.  I could then associate required fields with each transition in the workflow, and customers would have what they asked for ... fields getting filled in with good data to facilitate proper reporting.  To my knowledge, TeamTrack was the first defect tracking system to implement workflow, a feature which went on to be copied by nearly all defect tracking systems that came after it.

So let's review what I did.  I didn't conduct any interviews, but I had the luxury of not doing that because I had all the experience from DCS fresh in my mind.  The ideas I had weren't born of my own fanciful wishes, but were based on real problems experienced by real customers.

But there's something else that I think is also interesting.  In DCS, no one asked for a web-based interface, they asked for simpler client upgrades and faster inbox refreshing.  No one asked for hierarchical projects, but instead they asked for high-level reports across multiple projects.  And they didn't ask for workflow, they asked for a way to make sure fields got filled in at the right time.  It was then up to me, using the domain expertise that I had by now acquired, to map the customer needs into specific features.  That's an interesting part of the process.  You can't expect customers to tell you what features to add, they just tell you what their problems are and then you have to figure out how to design a system that will solve those problems.

So once again I think we see a combination of the two schools of thought about idea creation that I mentioned in Part 1 of this blog series.  Customer feedback was an important part of the process.  But so was applying personal ideas, creativity, and domain expertise about the problem.

In the next entry in this blog series, I'll examine how applicable these lessons are in the current era of software development.

If you're a software startup, how do you decide what to work on?  That's a question that I've put a  lot of deep thought into over the years.

As I've talked to people about this issue, there are two basic paradigms that standout.  They are extremes of each other, but they serve as useful pivot points for the discussion.

The one school of thought, headed up by my sales & marketing friends, says you should "Listen to your customers and do what they say."  Well, that sounds reasonable, but what if you're a true startup company and you don't have any customers?  Then who do you talk to?  My friends tell me that in this situation, you work your personal network, you make individual contact with people, you take them out to lunch, ask them very general, open-ended questions like "So Pat, what part of your job do you spend the most time on?", and then you engage in "active listening" to discern their needs.  After doing enough of these personal interviews, a common pattern of need will emerge, and there you have it ... you've got your product idea.

According to this way of thinking, you should not even begin to write your first line of code until you have lined up at least half-a-dozen reference customers who have not only committed to buying the product once it is available, but have agreed to pay you in advance for the costs of the product development.

The second school of thought, headed up by technically-inclined people such as myself, tend to think you should draw on your own personal experiences and your domain expertise in whatever field you are contemplating, think of a great idea, write the code, and once the product is available, begin the sales & marketing aspects of the business.  People who think this way are introverts by nature, and would love nothing more than to hole up in a cave somewhere, spend a couple of years writing the greatest product on Earth, and then tenderly and lovingly release its awesomeness to the world.

So which of these schools of thought is correct?  Probably neither.  But which one is closest to being correct?  I think there are probably examples of both kinds of success.  As I am currently working on my third startup company, for the sake of anecdotal data, let's examine my first two companies, which were both successfully sold to larger software companies.  How did those companies succeed?

In 1991 I was working as a software engineer at Hewlett-Packard.  During my tenure at HP, my project team was struggling to cope with the myriad of "to do's", bugs, and enhancement requests on the project.  We began using a very primitive UNIX-based defect tracking system named DDTS.  It sucked for two main reasons.  First, it used UNIX shell scripts as its core technology, which made it difficult to get useful information out of the system.  Just getting a list of defects assigned to you meant you had to write your own shell script.  Each engineer had to have their own personal script with their name hard-coded into it.  Second, it could only be accessed from a UNIX workstation, which meant I had to leave my PC-based development system, walk over to a UNIX workstation, and login to access DDTS.  How inconvenient.

From this experience I was aware that there was a need for defect tracking, and the current solution in place was very suboptimal.  I reckoned that the world could use something better.  While those thoughts were fermenting, my friend Bob Pinna told me he was going to leave HP and start his own company to make a defect tracking system.  Wow!  I'd been thinking about the same thing.  Bob had a few more years of experience than I did, and had done not just software engineering, but software project management as well.  I figured if Bob thought it was a good idea, then it probably was.  Bob drew on his personal  project management experiences, but also talked to several other project managers, mostly at HP, to figure out the initial feature set of the project.  Bob left HP and started working on the product full-time.  I stayed at HP and worked with Bob part-time to write the system documentation and help with testing.

When the product was ready, in October of 1992, and before we had made our first sale, I left HP to work with Bob full-time.  I had started at HP on August 1, 1990.  My last day was October 2, 1992.  My life as a salaried engineer working for a large company had lasted exactly two years, two months, and two days.  My life as a software entrepreneur had begun.  Our product, Defect Control System, or DCS, was released and sales grew rapidly.  Two years later the company was acquired by INTERSOLV and the product was renamed to PVCS Tracker.

Getting back to the idea generation process, in which two schools of thought does this model fit into?  To me it seems clear that some aspects of both methodologies were used.  Interviews were conducted and feedback was incorporated into the product.  The product was not developed in a vacuum.  However, the idea itself came from personal experiences of understanding the need for defect tracking, and understanding the weaknesses of the existing solution.  Interviews were done after the idea was decided upon, and for the purpose of honing the idea and deciding upon the exact feature set.  We showed the product to our friends who were still at HP, but there was no pre-commitment on the part of HP to buy the product once it was ready.

The process worked, although not without some misfires along the way.  One thing I remember is that because of the close ties we had with HP, the product had a Bugs per Thousand Hours report, which was an important metric used within HP.  Turns out, not too many organizations outside of HP were doing things that way, and the feature went mostly unused and was the source of a lot of customer confusion.  Other important features were missed, like the need to be able to create custom fields for tracking information specific to each organization.  Everyone did things a little differently.  The first version of DCS had custom fields, but you could only add a total of 8 custom fields, two text fields, and six drop-down selection fields.  This limitation turned out to be woefully inadequate, which we learned very quickly.  I don't think you'll ever get everything exactly right out of the gate, but hopefully you get pretty close.  I think we got a lot more things right than we got wrong.

In the next blog in this series, I'll talk about my second company, TeamShare, which made another defect tracking system, TeamTrack.

Well, it's tax season again, which means its time to get caught up on my financing backlog.  The number of transactions that I need to manage for my business is still small enough that it doesn't make much economic sense to hire a person to run the financing department, or even to bring in a part-time bookkeeper, so that means I get to do it myself.  What fun!  I think it's pretty much universally accepted that the thing small business owners hate doing the most is their books.  If anything should be delegated, it's that, right?  Maybe so, but I've found it informative to do it myself, at least right now.  When I do eventually hire someone, I'll hopefully be handing off something that's reasonably well organized rather than a shoebox full of receipts.

I use QuickBooks for my accounting system.  One of the big problems I have in my life right now is that I don't just have one computer.  I've got my primary desktop (a Mac Pro tower that I upgraded to last year), a laptop, several old secondary desktops, the OS/X partition on my Mac Pro, the BootCamp partition, several desktop-based virtual machines, a few physical servers, and some virtual machines that I've installed on the servers.  So a non-trivial question that comes up when using QuickBooks is "On which computer should I install QuickBooks?"

Up until this year I've been running QuickBooks 2003, and I've had it installed on an old AMD-based desktop system running Windows XP 64-bit.  I built this system myself about three years ago, but since I upgraded to the Mac Pro last year, the AMD machine got disconnected and pushed into the corner.  Except I never reinstalled QB 2003 on the Windows Vista 64 system that I run on the BootCamp partition of my Mac Pro.  Whew!!  So that means that just the simple act of logging into QuickBooks meant I either had to re-install QB on my BootCamp, or I had to dig out the AMD machine, hook it back up, and remote desktop into it.  I opted for the latter approach, since I couldn't find the QB 2003 disk and serial number, and even if I could have, I'm not sure I could have reactivated the software considering that it is such an old version.  Considering that I had to call Intuit for help three years ago when I installed QB on the AMD machine, I wasn't very hopefully that I could get it reinstalled this time.  I really hate software activation.

So I got the AMD machine running, remote desktoped, and got back into QuickBooks.  Fine.  But then I started thinking, well, maybe I should upgrade to QB 2009.  It's newer and nicer in some ways, it's got some features that I'd like to use more, such as better support for online banking and more third-party support, etc.  But I knew right away I didn't want a repeat of the "Which machine is it on?" fiasco that I just went through, so I came up with a new plan.  Now I know that QuickBooks has a hosted service that I could use instead of the desktop software, but I've always been nervous about putting such intimate financial details out on the Internet, and I didn't want to pay the monthly fee, so I decided to stick with the desktop software route.

I decided to go with the virtual appliance concept.  A software appliance is where you use dedicated software on a dedicated machine for a single, specific purpose.  Just like you use your refrigerator to keep food cold and your oven to bake stuff, you can create an information appliance to manage your finances.  A virtual appliance is the same thing, except that you run it on a virtual machine insteal of a physical machine.  So I created a virtual machine named VM-FINANCE that would function as an appliance for all financial-related activities, including not just the QuickBooks software and data file itself, but scanned receipts, etc.  I would also install the tax software on there as well.  I access the virtual machine by remote desktoping into it.

This means I won't install QuickBooks directly on my Mac Pro BootCamp, so if I upgrade to something else in a year, I can still access my financial appliance.  If I upgrade the server to a faster server, I can just migrate the virtual machine over to the new server (although I might run into some reactivation issues doing that).  Also, if I can get into it from my laptop, as long as I'm in the office.  I have to be connected to the business network.  I won't be able to access it on the road.  But for me, that's okay.  QuickBooks is not something I need to be able to get into while I'm on the road, and if I really had to, I could VPN into the home office and do it that way.  As long as I can remote desktop into the finance machine, I'm okay.

So far, this has proved to be a good approach.  The software does run a bit slower than I would like it to, owing to both the remote desktop software and the virtual machine emulation, but it's good enough for how often I use QuickBooks.  Hopefully now that I don't have to dig out the AMD machine each time, I will be more inclined to keep my finances up-to-date this year.

Hello, and thanks for visiting my blog.  I've decided to join the 21st century blogging community.

A brief background about me ... I'm a software engineer and entrepreneur.  I've been in the industry for 19 years.  In 1992 I co-founded a company, The Software Edge, which made the first defect tracking system available on the Windows 3.1 platform.  The product was named Defect Control System, more popularly known as DCS.  Two years later, in 1994, the company was acquired by INTERSOLV, makers of PVCS Version Manager, and DCS was renamed to PVCS Tracker to fit into the PVCS family of products.

In 1996, I started my second company, TeamShare, which made another defect tracking system, TeamTrack.  In 2003, TeamShare was acquired by Serena Software.  Coincidentally, a few months after acquiring TeamShare, Serena also acquired Merant (which had been born out of the INTERSOLV and MicroFocus merger), and thus Serena came to become the owners of both PVCS Tracker and TeamTrack.  I guess they really like what I did!  PVCS Tracker was eventually phased out, and for reasons which I'm still trying to understand and accept, TeamTrack was renamed to "Serena Business Mashups".

My current company, Timpani Software, is focused on continuous integration / software build management with the BuildBeat product line.

I current have a wide range of software interests, which I intend to blog about.  I hope you find these topics interesting.  Please comment on my blog entries.  I'm really looking for feedback on ideas I share.

• General thoughts on the software business
• Continuous Integration
• Version Control
• Defect Tracking
• Application Lifecycle Management
• Agile Software Development
• ASP.NET MVC
• ASP.NET AJAX
  
• WiX Installer
  

After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.