[Announcing Leadwerks 3]

Sorry, but I'll have to pass on this one.

Not sure where the rationale comes from, but I hope it works out for you as you seem like a decent guy.

I expected it to be more than LE2, like 500-1000 for the whole package, with a discount to current owners who could get it around 300 or something for a limited time, as I know this is a somewhat niche market, but 3K for new users, and $1500 for existing users...um, thanks, but no thanks.

 

I'll take a look again when there is a sale and/or there is more feature parity with competitive products.

 

Quite a let down for me, to say the least.

[Editor Documentation]

Looks good.

I'd like to see the following to make the search as useful as possible by creating references with as many similar terms as possible. One thing I find the hardest to deal with in new programs and/or code libraries, is knowing what I want to do, but not knowing what word(s) to search for to find it.

 

As an example. You're calling them CSG primitives created in the 3D view "brushes", or maybe it's a brush that draws them. Either way, if I was relatively new to the program and/or CSG modeling tools, I wouldn't know this, but I would know what a 3D shape, or a primitive, or a polyhedron was from basic geometry. So..having results come up for multiple keyword searches, is, IMHO a key feature of good documentation. Another good approach is being able to sort things in multiple ways, such as, what it does (physics, rendering, etc.), and alphabetically, and by it's class/code hierarchy if it's code.

 

The second thing I'd ask for is that the API reference have decent descriptions of what things do, what the parameters and returns are, and at least one small code snippet to demonstrate basic use. It drives me bananas when the docs are just some doxygen dump, filled with programmer pseudo descriptions that often just repeat the name of the class or function.

[Leadwerks Levels Up]

Congratulations on finding a closet to stuff yourself in. I'll expect a MASSIVE increase in productivity as a result.

[On the Naming of Things]

I wasn't referring to the "i" prefix, I meant to point out that iTunes is named for music, but does a lot more. However, the more specific name that captures most of what the program does is actually better than calling it "iMedia" or "iContent" or something more nebulous.

Well, iTunes, is a brand name, which is quite ubiquitous, and forum categories are not. Honestly the software iTunes is a horrible example IMHO of organization. I actually "do" have trouble finding things in iTunes because the movies and the music aren't separated in a very efficient way.

I understand the need to have less forum categories, and in particular sub categories. I completely agree, but lumping music/sound with graphics doesn't make ANY sense to me.

[On the Naming of Things]

The problem is, the categories still aren't "catchy" and are still generic. If you want to go the iTunes route, you should think up a neutral catchy name for each category, such as:

 

Lead:Code, or LeadCode.

Lead:Art or LeadArt.

 

etc.

 

Right now it's non catchy names that "also" don't make sense for all the items that would be placed in that category.

[Why Small Companies Succeed]

You can see this with Unity as well. In the very beginning they were much faster at getting the technology out, but with almost 100 staff, they still put out great stuff, but you can see that the efficiency portion has definitely dropped a bit

See I don't think that has to do with the amount of programmers they have, I think it has to do with the amount of processes they put in place to reduce the risk of someone releasing code that screws their program up. When they had 100 customers they could afford to screw up. When they have 100,000 customers, screw ups cost you more as it kills your reputation. They probably have to do change controls, then 3 people have to approve, a code check has to happen, then instead of making new releases every day they wait and package them together because nothing pisses people off more than having updates every single day because changes are it'll break something for you. These things are what you do when you are a big company to reduce risk and what you don't have to do when you aren't. That has nothing to do with the amount of programmers you have.

 

 

The number of programmers you have, assuming your statement to be true, which I agree it probably is, directly affects the number of potential errors there can be, and lead programmers ability to watchdog, those issues. Many hands, often spoils the soup, and the rate at which you can cook more soup does not increase linearly with the number of pots, stoves, and cooks, particularly if you have to make sure the soup is just as good, and tastes the same, in every pot, which inevitably has to be done by one master chef or a master and a very select number of understudies.

 

Another way to say it is, I think you are right, but it is a contributing factor, and what you are saying is compounded by the number or programmers, and is not an either/or counter to what Josh is saying.

[Why Small Companies Succeed]

I agree completely, and have experienced this myself when I was doing engineering. You can see this with Unity as well. In the very beginning they were much faster at getting the technology out, but with almost 100 staff, they still put out great stuff, but you can see that the efficiency portion has definitely dropped a bit (but probably not as badly as some because I think they do a good job at hiring people), and in many cases they've just bought in or licensed tech instead (beast, umbra, etc.).

 

The only way that large companies can stay really efficient is if they have a real brainchild managing the project who can layout every system ahead of time and delegate work to a bunch of really good "day to day" single task coders. People who can do that are few and far between.