Amazon.com Widgets December 2012

Comments should work

By Nick at December 28, 2012 09:14
Filed Under: Delphi

Sorry for the confusion -- comments should work now.  Thanks to Chris Timmons for pointing out the problem.

Flotsam and Jetsam #71

By Nick at December 26, 2012 10:40
Filed Under: Delphi, Flotsam and Jetsam, General, Software Development
  • I’ve shamelessly tweeted it a couple of times, and I’ll promote it here as well – I’ve created a Bookstore page here containing a list of books that I think are must-reads for all developers.  What books would you add to the list?
  • Have you upgraded to Delphi XE3 yet? If you haven't, please do.
  • Okay, I need some advice:  I want to learn a functional programming language, but which one?  Clojure?  Haskell? F#?  What? 
  • I need some more advice:  I have a good working knowledge of SQL and SQL Server.  But I’m going to need to become a SQL Server 2008 expert in the coming months.  Can any of you fine people recommend the best book or other resource for going from the basics to really being a guru?  Again, I’m looking specifically at T-SQL and SQL Server itself.

Rock-n-Roll Leadership

By Nick at December 09, 2012 20:03
Filed Under: Leadership

Who ever knew that the great .38 Special held the secret to a good leadership viewpoint?

Just hold on loosely
But don't let her go
If you cling too tightly
You're gonna lose control

Hold on Loosely” by .38 Special

That simple lyric holds a valuable viewpoint for leaders. The song, of course, is about a girl.  But imagine you are holding a small bird in your hand.  If you hold the bird too tightly, you’ll crush it.  If you hold the bird too loosely, it will escape. But if you hold it just right, not too loosely and not too tightly, then the bird will stay in your hand, and maybe even feel safe.  And if you focus on it, it’s probably not too hard to figure out just the right amount of pressure to keep the bird in your grasp.

It’s the same way with leadership.  One of the toughest decisions leaders make is how much control to exert over their people.  It’s a delicate balance.  Both too much and too little can cause difficulties and cause you to lose your team.  Finding just the right amount of control is a large challenge. 

The tendency of many leaders is to “cling too tightly”.  They tend to want to have close control over their people.  They want to make sure every little detail is taken care of, setting rules, procedures, and processes for every little thing to ensure that things never get out of control.  They view their people as merely cogs in machine, and thus give them little autonomy to make decision, innovate, improvise, and otherwise come up with their own solutions.  They make every decision, ensuring (in their minds) that things are going perfectly.

There is a word for this – micro-management.  No one ever thinks that they are being a micro-manager.  In my experience, the more a leader micro-manages, the more he thinks he isn’t.  Micro-managers tend to think that they are providing leadership because it’s needed, because their team can’t be trusted, or, sadly, because they think that their team is simply incompetent to do the job.  Or perhaps they feel that they have to be involved in order to get the credit.

Whatever the reason, a leader who clings too tightly is being ineffective and usually has a negative effect on her team.  People feel the lack of trust, and that’s demoralizing.  Teams that are given little autonomy soon lose their desire to improve and find better ways to do things.  When their leader has all the answers and always knows what is best, why even try?

But holding on too loosely can have a similar effect.  If a team feels that their leader can’t make decisions or is wishy-washy, then they feel adrift and unsure.  No one likes a ship captain who doesn’t know where the ship should be going.  And a ship that is headed nowhere will surely get there.  Not making any decisions is no better than making all the decisions.

The trick or course, is to hold with just the right amount of pressure.  Good leaders find that perfect balance between control and chaos.  They let their team decide how to accomplish tasks within general guidelines.  They encourage improvisation and innovation in a search for better ways of doing things.  They know that there are some things that need to be done a certain way, but that there are many things that don’t.  They trust their team to get things done their own way. They know that if a team member gets credit, it reflects positively on their leadership. 

In general, they hold just tightly enough to keep things in control.  They let team members make decisions.  They recognize that mistakes will be made and that daring to do something different is a feature, not a bug.  They make decisions when the team needs a decision, and they delegate decisions as much as possible.  They recognize that they have a tendency to “squeeze to tightly” and thus, when in doubt, tend to err on the side of holding too loosely.  They understand that autonomy and self-direction are very satisfying, and do everything they can to provide that to their team. 

Just as a good veterinarian knows how to hold a bird with the right amount of pressure, a good leader knows the precise amount of control to exert over his team.

Blast from the Past: Developers and Economics

By Nick at December 04, 2012 20:45
Filed Under: Software Development, Delphi

Here's another article from my series at CodeFez -- and here's the response that Steve Teixeira wrote to it.  The comments on both are a pretty interesting discussion.

I never cease to be amazed at how little the average developer knows about economics. I mean, I don't claim to be an expert, but I have taken a college class or two and read up on the basics. Even just understanding the basics, though, gives one surprising insight into why things happen the way they do in the marketplace.

For instance, we are in the process of hiring a new developer at my company. We figured out what qualifications we were looking for and determined about how much salary we wanted to pay. It quickly become apparent, however, that we weren't offering a high enough salary to attract the caliber of candidates we wanted. So what I did was to go on the newsgroups and start whining about not being able to find any good Delphi programmers. Okay, no, I didn't really do that. What we did, of course, was to increase the salary that we were offering. Simple supply and demand issue: There wasn't enough of a supply of good Delphi programmers at the price we wanted to pay, so the solution is to be willing to pay more – a no-brainer decision, really. Once we did that, we found that we have been able to find plenty of valuable candidates. Simple economics.

One common area that I see developers totally misunderstand is that of Delphi pricing. One thing you learn in Economics 101 is that the vast majority of companies are “price searchers”. That is, they are constantly searching for a price that will maximize their profits. (Some companies, mainly producers of commodities, are “price takers”. That is, they take whatever price is offered. Farmers are a good example. A corn farmer can only sell his corn at market price. If he asks for more, the market will simply buy corn from another farmer that will take the offered price). Borland is definitely a price searcher. They can set their prices as they please, and will do so to maximize profit. Of course, the market will respond to any particular price by demanding a certain number of units at that price. Price searchers are constantly adjusting prices to maximize the amount of money they make.

Note that they don't set price to maximize revenue, but rather profit. The cost of goods sold is a factor here as is the cost of simply having customers. Sometimes a company will actually price a product in order to limit the number of customers they have in order to maximize profits as sometimes having additional customers causes decreased profits. (That may be a bit counter-intuitive, but think of a product that has high production and support costs.) So for example, sometimes doubling your price can increase profits even though it drastically reduces sales. If doubling the price cuts the number of customers you have in half, but also cuts your production and support costs in half as well, your profit increases. (This is a very simple example, and it is actually hopelessly more complicated than that, but you hopefully get the basic idea).

So Borland, having learned from years of experience and copious sales data, is quite aware of what effect various prices have on sales. No doubt by now they have a pretty good idea what price will maximize their profits and how price changes will effect sales.

Where it gets really interesting is pricing outside of the United States. Europe, of example, is a completely different market than the US. Taxes, the demand curve, and the number of potential customers are all different. Borland clearly believes that they need to – and can – charge more in Europe than in the US. The price difference is not related to the exchange rate between the Euro and the Dollar; it has everything to do with maximizing profits. Clearly Borland believes that a higher price in Europe – again, a completely different market – will mean higher profits. That's why Delphi costs more in Europe. I suppose Europeans could view this as “price gouging”, but in reality, it's just the market signaling to Borland that it will bear a higher price than will the American market. Simple economics.

Another economic blunder that developers frequently make is ignoring economies of scale. Borland is a big company that is publicly traded. Many Delphi developers work in small, private companies. Borland has legal obligations, overhead costs, and market demands that most little-shop developers don't even know about, much less take into consideration. Borland's main competition is one of the largest corporations in the world. Borland faces investors who expect a return. Borland has to deal with major entities in the media that can write things that can have profound effects on Borland's business. All of this combines to make running Borland a complex and difficult task that most of us simply don't comprehend.

So I love it when a developer posts in the newsgroups something like this: “Borland should just hire two college students to go through and fix all the Delphi bugs in Quality Central.” Well, that sounds great, but is clearly isn't that simple. First, fixing bugs in a big product like Delphi is no small, trivial task. Finding people with the talent and skill to do Delphi bug-fixing isn't easy. And they certainly aren't going to be cheap. The notion that some college interns can do it is quite naïve. The economic blunder comes, though, in thinking that the cost of fixing all those bugs is merely the salary of a couple of developers. First, employees aren't cheap, no matter who you hire. Human capital is by far the most costly – and valuable – part of doing business. Secondly, I don't know what your development process is like, but bug fixing at Borland is more than a guy hacking out some code. Every fix has to be extensively tested for efficacy and correctness, and then the whole product has to be regression tested to ensure that any given fix doesn't actually break something else. Fixes need to be incorporated into shipping product and distributed to existing customers. The documentation needs to be updated. And who know what else needs to be done? The point is this: the costs of things that many people think are small are in fact much larger than the average developer appears to realize.

The economics of running a business like Borland isn't something about which I claim to be an expert. But I do know that I don't know enough to be able to claim to know better than Borland. Something to consider before you fire off a post in the newsgroups that starts out “Borland ought to just....”

Blast from the Past: My Plans for DevCo

By Nick at December 03, 2012 19:30
Filed Under: Delphi, Blast from the Past

Now here is a true Blast from the Past from March 8, 2006 during the early days of "DevCo".  This one ought to provoke some discussion.  What of this list has actually come to pass? 

Joe Mele tossed his name out there as the potential CEO of DevCo.  Well, I'll throw my hat in the ring as well.  And not only that, I'm here and now putting out my official plan of action for my reign as the leader of the premier development tools company.

My plan is divided into three different courses of action:  What I'd do immediately, what I'd look into doing, and wild-ass ideas.

Here's what I'd do for sure right away, no questions asked:

  • Put a full page ad in every issue of SDTimes -- I've asked about this before.  I can't understand why Borland hasn't been doing this all along.
  • Put the help in a Moderated Wiki -- As I understand it, this is in the works,  but it really needs to happen.  We all together can build a better help file than the Delphi Docs Team.  No offense to them, but it's a big job.
  • Release a "Delphi for .Net SDK". -- This totally needs to happen.  The lack of a public compiler is killing the third-party Delphi market.  Just killing it. 
  • Double, no Triple, no QUADRUPLE the budget for what is now BDN -- BDN will be even more important to DevCo.  It's totally underfunded now. As the CEO of DevCo, I'd fix this right away.
  • Double, no Triple, no QUADRUPLE the size of the documentation team. -- Somebody is going to have to manage all this inputs that we community members put into the Help Wiki.
  • Provide a competitive upgrade price from any other development tool -- How are you going to woo VB6 developers without a competitive upgrade?
  • Give every person in the company, all the way down to the cleaning crew, a copy of The ClueTrain Manifesto -- Oh man, this really, really, really needs to happen.  Could there be a company that was less ClueTrain-ish that Borland?
  • Plan, and announce as soon as possible, the new, improved, exciting DevCon -- Get the faithful together as soon as possible.

These are the things I'd look in to doing.  I wouldn't necessary do them, but I'd throw them out there and look seriously at them:

  • Find a way to aggressively pursue VB6 developers -- The field is still rich for the sowing. How can we get to these guys?
  • Look into the right way to release a Standard/Personal/Free version of Delphi - This is hard.  Sell a low end version, and people buy it instead of the more expensive versions.  Don't have a low end, and you don't get students, hobbyists, and other new folks on board.  There has to be a way to solve this.
  • Look into instituting a subscription selling model -- Smooth out the development cycle and the revenues.
  • Sell licenses (not boxes, just licenses) of any version of Delphi -- There are folks out there using older versions of Delphi, and DevCo should make it easy to expand the size of their development team.  Or, put another way, if people want to buy something you have, sell it to them.
  • Revitalize and release NDatastore -- This product would simply rock, and the entire .Net development world would buy it, not just Delphi users.
  • Open up "DevCo Press", using on-demand printing technology -- On-Demand printing will keep costs way down, make keeping multiple titles available, and allow for more esoteric topics to be available. 
  • Institute an Affiliate program, allowing people to sell Delphi from their websites -- the more folks selling and promoting Delphi the better. 
  • Look at harnessing the power of the community
    • Club DevCo -- figure out ways for folks to earn points by being good community members.  Points can earn free stuff.
    • Free marketing materials to anyone who asks -- put together a package the ordinary folks can use to promote Delphi.  Give it to anyone who asks.
    • Free bumper stickers and other swag -- get the word out ASAP.
  • Look into buying/merging with/closely partnering with FinalBuilder, AutomatedQA, Altova, Modelmaker and Castalia -- These folks make products that Delphi developers want.
  • Add syntax highlighters for Ruby and Python for starters -- These to languages are just getting too popular to ignore
  • Release a VS.NET version of ECO - ECO is awesome technology.  Consider letting the VS.NET guys in on it.  They'll pay.  ;-)

Here are a few ideas that are really out there, but worth at least thinking about:

  • Integrating a VB6 personality into BDS -- why not?  That would be one way to get them involved.
  • Create a personality for Javascript/AJAX development -- This is getting hotter and hotter everyday.  Someone will do this first.  It ought to be DevCo.
  • Add a personality for Python and/or Ruby -- Do this after the AJAX personality.

Just a few thoughts for the new CEO, whoever it ends up being.  Smile

My Book

A Pithy Quote for You

"Always be a first-rate version of yourself, instead of a second-rate version of somebody else."    –  Judy Garland

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.