Pathfinder 1E Hero Lab Supports Pathfinder Roleplaying Game!

[dinelendarkstar]

For those of us following along, what development platform would you be referring to?

REALBasic.

 

[Nylanfs]

Great Job guys!

Finally recovering from GenCon and catching up on forums.

 

[azhrei_fje]

It's frustrating when very bright people take a myopic view of business from a single vantage point, without considering that there might be other factors involved. This lack of perspective results in blanket statements being made that are wholly inappropriate and patently incorrect.

I apologize for my choice of words. A bad mistake on my part.

I am impressed that you continue to develop the product with just two programmers on staff! Those must be some true hotshots to cover such a large code base!

I haven't worked in a proprietary software environment for ... about 20 years. (Hmm, actually closer to 18.) And even then it was in an industry in which the sale of an application suite was expected to include source code, although the license was still quite restrictive. (Those who were around in the heyday of mainframes may remember that such machines always came with source code to the operating system.)

When I referred to "fear of change" I was talking about the overall environment. For example, suppose you have two programmers on staff that both know C++ very well but know little or nothing about Eiffel. Even if Eiffel provides the absolute "best" environment for writing a new application there will be that fear of something new, that fear that perhaps the programmers won't pick it up quickly enough or that the compilers will have bugs or that deployment will be difficult or... These fears are often a large factor in driving management to make a business decision against switching to another language. (This is obviously a blanket statement and won't apply in every situation or to every company, which is why I used the term "often". For an analysis of this 100% human reaction, Google for "software risk analysis" and "risk avoidance". This is a documented artifact of the software development industry.)

An interesting corollary is that such a business will always be playing catch up with others in their market: they can never be at the front of the pack because they cannot truly innovate. Oh, they can develop new features or extend existing features, but they are always held back by the existing code base and having to work within that framework. Innovation requires change, quite often a very radical change. (Ask your programmers how much of the code base they'd like to rewrite if they had the chance. It will likely be about 30% of the code and the largest portion of that will be library functions that are used frequently. See Martin Fowler's book, UML Distilled for his empirical evidence.)

Sorry, I've started rambling. I'll stop now.

And then people like myself are left with the choice of either ignoring the misinformation (and allowing it to propagate through lack of any challenge) or rebutting it (and thereby having to "dress down" someone who I'm sure means well). It's a lose-lose situation, and I hate being stuck with it.

Again, I'm sorry. My tone above was inappropriate and I don't have any excuse for it. I was a bit exasperated at the entire Windows software development industry and took it out on LWD.

The next time you're in Tampa, drop me a note and the first (and second!) beer will be on me.

 

[LWDPressRelease]

I am impressed that you continue to develop the product with just two programmers on staff! Those must be some true hotshots to cover such a large code base!

Thanks. We stay pretty busy.

Those who were around in the heyday of mainframes may remember that such machines always came with source code to the operating system.

I've been doing software development - for pay - for 29 years now. So I remember those days.

When I referred to "fear of change" I was talking about the overall environment. For example, suppose you have two programmers on staff that both know C++ very well but know little or nothing about Eiffel. Even if Eiffel provides the absolute "best" environment for writing a new application there will be that fear of something new, that fear that perhaps the programmers won't pick it up quickly enough or that the compilers will have bugs or that deployment will be difficult or... These fears are often a large factor in driving management to make a business decision against switching to another language. (This is obviously a blanket statement and won't apply in every situation or to every company, which is why I used the term "often". For an analysis of this 100% human reaction, Google for "software risk analysis" and "risk avoidance". This is a documented artifact of the software development industry.)

I wholly agree with this tendency. I find myself tempted down that path as well sometimes. But, with our tiny size, its more about expedience and not losing all the time spent spinning up on new technologies. That being said, we're actively switching over to another language for an upcoming product that isn't substantively tied to our existing codebase. So it's a balancing act.

An interesting corollary is that such a business will always be playing catch up with others in their market: they can never be at the front of the pack because they cannot truly innovate. Oh, they can develop new features or extend existing features, but they are always held back by the existing code base and having to work within that framework. Innovation requires change, quite often a very radical change.

On this point, I disagree. Such a business will *sometimes* be stuck in catch-up, but switching to a wholly new language or toolset is *not* required to innovate. Languages and toolsets are merely tools that a good developer keeps readily available in his toolbox. You come up with an idea and then choose the best tools for the job. Sometimes, one particular tool is clearly best for the task, but many times, the pros and cons of different tools result in multiple tools that are roughly equal in utility for completing the task. If any of those tools is one where you already have greater competence, or if using a familiar tool will save you many months or a year in development time, the "best" tool for the task from a business standpoint is *not* necessarily the best tool from a purely technical standpoint. So it's all a matter of ensuring the business is being smart overall.

Ask your programmers how much of the code base they'd like to rewrite if they had the chance. It will likely be about 30% of the code and the largest portion of that will be library functions that are used frequently. See Martin Fowler's book, UML Distilled for his empirical evidence.

I'm one of the two developers, so I'm very familiar with this issue. We're also very proactive about this. We periodically rewrite large chunks of our framework, evolving it over time, so that number is below 30% for us. However, there are definitely still a few areas that would seriously benefit from a rewrite. Those are the areas we'll likely be hitting the next time we revamp chunks of the codebase.

Again, I'm sorry. My tone above was inappropriate and I don't have any excuse for it. I was a bit exasperated at the entire Windows software development industry and took it out on LWD.

No problem. As I assumed, you meant well, but the words could have been chosen better. And I don't blame you for being exasperated at the software development industry. I was a developer here in Silicon Valley for 15 years and got fed up with it, so I went freelance for awhile and finally ended up creating my own products.

The next time you're in Tampa, drop me a note and the first (and second!) beer will be on me.

Sounds like an opportunity to share lots of war stories.