The New Release Pattern

Are you on Update Subscription for RAD Studio?

You are?  Great.  Wise move.

You aren’t?  Why not?

We are very interested in you being on Update Subscription — so much so that you pretty much have to be when you upgrade.  We do this because Update Subscription is really great for you, and not bad for us, either.

It is great for you because you pay less over time.  It is great for you because you always have access to the latest and greatest versions and features.   It is great for you because you can budget annually for your software development tools.

And it is great for you because it incents us to release software when it is ready, and no sooner.  Because we no longer have to wait a whole year or more to release new features (as we did previously without Update Subscription), we can more gradually release features when they are ready.  We don’t have to push a feature to make a date because we know that there’s another date not too far off where we can ship that feature. We don’t have to pile a bunch of features into a single release to make it sound “big”.

For instance, C++ for Linux is proving to be a bit more challenging that we thought.  We originally planned to release C++ for Linux with the 10.2 (Godzilla) release.  But we don’t have to, and so we aren’t.  Instead, we are going to get Delphi for Linux in your hands as soon as possible, and then get C++ for Linux in your hands a bit later, when it is ready.  You get quality software sooner, and later.  We ship Delphi for Linux now, and then in a few short months, we ship C++ for Linux in the 10.2.1 release.

Okay, a little terminology.  Because of the fact that we can — and will — ship new features in all of our releases, we are going to stop  using the word “Update” and start using “Release” for all of our, well, releases.  Why?  One reason is because we find that many customers think of an Update as bug fixes only.  That isn’t true, and we don’t want to give that message by using the word that has meant that in the past.  Another reason is that “Release” connotes newness, and that’s the message we want to send.  So from now on, it’s Releases, not updates.  Everything we ship will be a release.

We can do this because you all are on Update Subscription.  Why is that?  Suffice it to say that it has to do with arcane accounting rules.  I know — that sounds lame, but it’s true.  Trust me, you don’t want to know the details.

Because of Update Subscription, we can now do two or three (or more if we want) releases a year.  We can deliver a constant stream of new features and quality fixes.  We are committed to making that upgrade path as smooth as possible.  We want you to be happy with this steady stream of goodness because we want you to renew your subscription when the time comes.  From now on, we make our money by continuously delighting you, and thus we are highly incented to do that.  That means quality and valuable new features on a steady and continuing basis.  It means we can ship no code before its time.

We have lots in the pipeline to keep you delighted.  We can ship these new features when they are ready.  That’s big win for everyone.

What is RAD Server and How You Can Use It?

I’m digging the new job. Lots of interesting things going on. Lots of great plans.

Now, you may not realize it, but I’m the Director of Product Management for all the Embarcadero products,  including a very cool product named RAD Server.

Many of you may have heard of RAD Server, but aren’t exactly sure what it is or why you’d want or need it. Well, read this blog post, and you won’t wonder anymore.

At its root, RAD Server allows you to build REST Server APIs with Delphi and C++Builder. You can read up here on what, exactly, REST is.

REST is beautifully simple. It functions on the notion that the four operations of the HTTP protocol – GET, POST, PUT, DELETE – correspond quite closely to the four CRUD operations – CREATE, READ, UPDATE, and DELETE. REST (along with JSON) has to a large degree taken over what SOAP and Web Services do/did.

So RAD Server accelerates building modern REST applications, services, and micro-services with Delphi and C++ Builder. This allows you a terrific amount of flexibility. First, you can easily build a back-end for a mobile application. RAD Server can provide a JSON-based REST API that your mobile application can use to manage all its data needs. The “heavy lifting” gets done by RAD Server, and the mobile application deals entirely with JSON. Nice.

In addition, because it uses the industry standards of REST, you can build any client front-end that you want for your RAD Server application. Any tool that can consume JSON via HTTP can be used to build a RAD Server client. PHP, Javascript, Angular, C#, whatever – doesn’t matter. As the graphic below shows, you can leverage almost anything to consume a RAD Server service.

image

And of course, you can build a very nice REST client using the tools in RAD Studio.

Leverage Delphi and C++Builder

But the real power comes in that you can write your code in Delphi or C++Builder. It’s pathetically easy to create a powerful set of REST API endpoints using a RAD Server plugin built with Delphi. You have total control over the URLs and the results of those URL requests. You can use FireDAC to access your favorite backend database. You can, literally, build any REST service with the full power of RAD Studio. Another cool thing – it’s naturally really easy to leverage your existing code base and transform it into a REST API.

Built-in Services to Get Up and Running Fast

But wait, there’s more! RAD Server includes a full-featured set of built-in core services to power application back-ends, meaning that you don’t have to build any of them yourself. Such core services include User Directory services, Authentication, and Access Control, Push Notifications, JSON data-storage, etc. These services are all ready to go right out of the box.

REST API applications are different than the typical Client/Server application. You’ve heard me ranting about loose coupling for years now. Well, there’s no looser coupling than a thin REST API serving up JSON. Separating business logic from the client is a natural as falling off of a log. Basically you are building a different form of a multi-tier application. Thus, RAD Server is a great complement to DataSnap by providing another, industry standard way to build multi-tier applications.

Want to get started? RAD Studio Enterprise includes a test version of RAD Server that allows you to build RAD Server applications via packages.  It’s very easy to get going. 

A Simple Use Case

One of our customers had a client server app for order management. In its old form, a separate server was installed at every store. The development team used RAD server to re-architect the front-end with a Javascript Angular web-based client and the back-end with RAD Server.   In only three months, they had a robust application that can service a host of new stores with minimal infrastructure investment. At first, they were considering a costly parallel Java development that was going to take over six months and require a whole separate team. Want to find out more about this customer? Watch this great video by our partner Malcolm Groves of CodeInsight.

Conclusion

There never has been a better time to move to a multi-tier architecture that separates your concerns and makes your applications both easier to maintain and more flexible. RAD Server allows you to migrate existing code to a more robust, modern architecture using REST APIs. Keep your eyes peeled for a Webinar covering all of this in the coming weeks.

In addition, we’re going to be running some pretty compelling sales programs that will make it easier than ever to get started with RAD Server. All in all, RAD Server is a bargain and you should give it a closer look.

Registering Primitives in the Spring Container

I just got back from attending EKON 19 in Köln, Germany. I had a really good time and learned a lot. In fact, I learned the most in one of the sessions I gave – a three hour workshop on Dependency Injection.  Stefan Glienke was there – he maintains and enhances the Spring Framework – and he showed me something that the Spring Container can do that I didn’t know it could do — resolve primitive values by name and an anonymous method.

Here’s how this works.  First, we’ll take a look at a simple class:

This is a simple class — so simple that I won’t bother showing you the implementation, which I know you can figure out.

What is cool, however, is that you can inject both Name and Age properties.  I’ll demo one as a constructor-injected parameter, and the other as a field-injected value.

First, we’ll register the Name property.  We’ll get the name property using the following function that gets the user’s Windows Name:

This is just a wrapper around the Windows API call GetUserName.  The real fun is here:

First, we register the TPerson class so that the container can resolve things for it. Then we register a string with the name ‘name’, and delegate its “construction” to an anonymous function that calls our GetLocalUserName function. The point here is that we now have a “handle” – the string ‘name’ – to a string value that can resolve at runtime. We do the very same thing for the FAge field. That might seem like over-controlling things, but in effect it is quite powerful.  We can use it to ensure that both interface and primitive values in a class are resolved with the Container.  Imagine a constructor that requires not only interface dependencies, but a string value as well.  You can let the container resolve the values for the entire class.

Now, all we need to do is to change the above class to have these attributes:

Now, the Name property of the TPerson class will automatically be filled with the Windows user name without actually writing any more code to make it do that. The FAge field will be set with our favorite number ’42’.

(The code for this application can be found here.)

Now, at this point I bet you are asking “Why would I do that?”

It does, on the surface, seem like a bit of overkill.  But, in the world of Dependency Injection, being able to resolve all the dependencies of a given class – interfaces, classes, and primitives  — is golden.  Not having to write code, and centralizing the resolution of constructor parameters, properties, and fields –no matter what the type — are very useful indeed.  Remember, the more you can decouple your code via the Container, the better.

And you don’t even need but the one call to the ServiceLocator.

More Coding in Delphi

I hope most of you have heard by now, but my second book is out and it is called “More Coding in Delphi”.   It’s a book very similar in nature to my first book (Coding in Delphi, which is still very much for sale) in that it covers coding techniques for Delphi Developers. 

You can get the book for free if you own Delphi XE8.  If you don’t yet own Delphi XE8, I suggest you upgrade, get the great product, and then get both my and Marco’s new book as well – both for free.  It’s a win all around.   Sorry, but the only way to get the ebook is to be a Delphi XE8 owner.  Well, I shouldn’t say sorry; as I said – it’s a win for everyone to own XE8. 

If you want a paperback copy of More Coding in Delphi, you can buy it from CreateSpace.  You can also buy it on Amazon, but you’ll be doing me a favor if you buy it from CreateSpace – my royalty is markedly bigger there.   CreateSpace is owned by Amazon if that makes a difference, and you’ll get the exact same book either way.

Here’s the Table of Contents of the main body of the book:

  • Six Things Before We Start
  • Writing SOLID Code
  • Patterns
    • Factory Pattern
    • Observer Pattern
    • Adapter Pattern
    • Decorator Pattern
    • Command Pattern
  • Operator Overloading
  • Multi-Threading and Parallelism Overview
  • Using TThread
    • The Parallel Programming Library
    • Parallel For Loops
  • Interception and Aspect-oriented Programming
  • A History and Review of TSmiley

In addition, here are also Appendices about Duck Typing and “Things Nick Does When He Codes”. 

More Coding in Delphi was a lot of work, but well worth it. It’s quite satisfying to complete a book. 

I hope you like it. 

You are going to pay for bug fixes. And you’re going to like it.

The day is coming when you are going to have to pay to get bug fixes.  You won’t like it at first, but that is the way things are heading.  And you should like it.

I can remember the day when software came with free support.  You had a problem, you called up the company and spoke to a tech support representative who would help you with your problem.  For free.  For hours if need be.  It was expected.  Of course a company should support a product that they sold.  If it wasn’t easy to use or didn’t work right, they need to make good on it. 

You might, at this point, see where this is going.

Then, of course, economics caught up with the marketplace, and companies began to charge for support, sometimes upwards of $100 an hour. People didn’t like it at first.  But even that became uneconomical as the internet appeared, and people stopped paying for support when they could get free support on the internet.

I can remember the day when software came with a stack of manuals, sometimes two feet high.  Anyone remember the Borland C++ 4.0 box? It was so big it had a handle built into it.  (I looked for a picture of it, but couldn’t find a good one…)  Of course the company should supply physical documentation with their product!

Then, of course, economics caught up with the marketplace, and companies couldn’t afford to ship all that paper with the product, and the documentation became digital and shipped with the DVD.  Hard copy documentation fell by the wayside.  People didn’t like it at first.

I can remember the day when software came on DVD’s, and when you ordered a new version of your favorite software package, they mailed you a DVD with a nice case.  (Shoot, I can remember when they mailed you 3.5” floppies, but that’s another story.) Of course the company should send you a physical copy of the software.  You paid for it, damn it, and you should get a disc! 

Then, of course, economics caught up with the marketplace, and now, you don’t even get that DVD.  Instead, you get a download link for an ISO file and you burn your own DVD if you want a physical backup. Or you just download an installer.  More likely you simply stored the software file on a backup hard drive or, now, in the cloud.  People didn’t like it at first.

You definitely should see where this is headed now. 

Pretty soon now, we’ll all be looking back on the day when you actually bought a stand-alone license for your software, and you got bug-fix updates with that single purchase.  Of course a company should give bug-fixes for free – the product should work right in the first place, and so why should I have to pay to get bug fixes?

But the economics of that are going to catch up with everyone, and soon companies are going to stop selling licenses and start selling only subscriptions.  And in order to get updates – including bug fix updates — you will have to have a subscription.  People won’t like it at first. 

The future is already here for many software tools.  Adobe sells only subscriptions for their highly popular graphics tools.  Office 365 is sold as a subscription.  And if you own either of those, you are – surprise! – paying for bug fixes.  This is a trend.  Microsoft and Adobe are not small software vendors.  You will see more and more software tools being sold this way.  It’s inevitable, as economics and the marketplace do their thing and technology enables new business models.

A pause for some thoughts:

  • It’s a silly thing to believe that the complex software that you buy should be bug free.  No non-trivial software is bug-free.  All software is buggy.  Everyone knows this.  Developers, in particular, should know this.  Yet people still argue that the product should be bug-free and that they should be entitled to free bug fixes because they “paid for a product that should work out of the box”.  Well, I hate to break it to you, but no software “works right out of the box” and there is nothing that developers can do about it.  I’ll say it again:  all non-trivial software has bugs and there’s nothing to be done about that.
  • Even brilliant developers develop code with bugs in it.  Even a clairvoyant QA team won’t find all the bugs. 
  • All software development requires intense human labor.  Bug fixing requires intense human labor. Companies cannot afford to do things for free.   Good developers and QA people are not cheap. 
  • Thus, as we saw with free support, documentation, and DVD’s, something has to give.  And that something is the notion of “buying a single, stand-alone license” for your software.  It’s going to go away.  Software companies are slaves to the marketplace just like every other business in the marketplace, and they are being driven to a subscription model just like they were driven away from free and then paid support, as well as stacks of paper for documentation and DVDs for software distribution.

People won’t like this at first.  But they should. 

First, the overall cost of a subscription will be less than purchasing upgrades.  Subscription fees have so far proven to be a remarkably good deal.

Companies will have vastly more flexibility to add features on a more frequent basis rather than in yearly (or longer) upgrade cycles.  Companies that sell only subscriptions can also talk more freely about their future plans because – and I am mentioning this with great trepidation – they won’t have revenue recognition issues with regard to future-looking statements.

And yes, companies will be more motivated to fix bugs – perhaps even bugs in previous versions.  Because they will have a steady stream of revenue and because they will be off the “one big release” mentality, they will have more leeway to fix bugs.  Because they can bring features to market sooner than they might have before, they can spread the pressure of releasing new features over longer, less focused periods of time.  Removing shipping pressure increases quality. 

Some will argue that a subscription model incentivizes companies to care less about quality.  This is nonsense.  It will incentivize them to care more about quality, because there will be no more excuse not to increase quality.  If quality doesn’t increase, people won’t renew their subscriptions.  And companies will be very, very interested in renewed subscriptions.  Low quality will not be a good business model while providing subscriptions.  Since feature pressure will be reduced, quality can become more prominent.

Yeah, people won’t like this change.  You are probably firing up the comment dialog box as I type this.  But I think we all see the benefit of free internet support like StackOverflow, online documentation like wikis, and software downloads that get you your software immediately.  Those were changes that we didn’t like at the time, but that we see the value in now.

And so it will be with software subscriptions.  So, yes, you are in essence “paying for bug fixes”.  But bug fixing is both inevitable and costly.  However, you’ll also be getting more frequent updates, more frequent new features, higher quality, and more openness about the future.  You’ll always have the latest and greatest version of your software package.

Who doesn’t want that?

Trailer Hitches and Software Development

When I was in the Navy, I had a friend named Tom.  Not only a great naval officer, aviator, and all-around good guy, he was also a good husband.  And by good husband I mean that he modified his beloved Ford truck to include a tow hitch for his wife’s horse trailer.  It was a big horse trailer and he had to get one of those hitches that was attached into the bed of his truck.  It was a major change.

Being the wise man that he was, he went to get some estimates.  The first one he got was a reasonable price, but the second one was twice what the first one was.  Tom asked why, since the first price wasn’t small, and the second guy’s price was pretty hefty.  The guy said “Well, you can pay me to do it the right way, or you can pay that guy and then have your hitch rip off and have your horse trailer go careening off while you are cruising down the highway”.  The point, of course, was that there is an upfront cost to doing things right that can prevent even more costs down the road (literally, in this case). Needless to say, Tom went with the second guy.

“It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.” — Max Kanat-Alexander

This quote came from a book I read yesterday called Code Simplicity: The Fundamentals of Software
It’s a short book – I read it in a couple of hours – but it is a good one.  Full of wisdom about software development, it makes the point that no matter what, your software is going to change.  And when it changes, you will introduce defects, so you need to make it as easy as possible to change your code in order to minimize the bugs you introduce when changes occur and decrease the difficulty of adding new features. It’s a really good book – give it a read.

The bottom line of the book: – In order to manage complexity in the large, you need to code for simplicity in the small. Complexity is the key, and how you manage that will dictate the long-term success of your project.  It’s amazingly easy to create complexity, and it takes a lot of work to create simplicity.

So code is like the trailer hitch – you need to put your costs up front in order to avoid disaster in the future.  As Kanat-Alexander says – we need to put effort into the implementation of our code in the beginning so that costs are minimized during the maintenance period.  We need to plan for the long haul, designing our systems up front to be flexible and changeable and composed of simple modules.  You can build complexity by combining simple modules into a complex system.  Simple modules are easy to maintain.  You can also build complexity by combining complex modules, but complex modules are difficult to maintain.  

There is no up side to the “Get it done quick and we’ll worry about fixing bugs later” way of doing things.  “You can pay me now or you can pay me later” is how the old saying goes, and it’s as true for software as it is for horse trailer hitches. 

Targets and Estimations

We’ve all been there.  “How long will this take to get done?”.  The answer they are looking for is “by this afternoon,” but most often the real answer is longer than that, often much longer.  In fact, the real answer is “I don’t know”.  But you have to give an answer.  This is where you hear tales of people rolling dice or making something up or saying “six weeks” no matter what.  In the end, you can’t know for sure because you’ve never done that project before, and so you make your best guess and it works out somehow most of the time.

But a lot of developers and managers fail to realize that there are really two different kinds of answers you can give.  If it is Monday, you can say “I’ll have that done by Friday”.   Then you work like crazy, and just before you go home on Friday, you deliver what you promised. 

The other type of answer you can give is “That will take 40 hours.”  And so if it is Monday, and you say that, then the manager will hearI’ll have that by Friday”.  So then you go and you work like crazy, and just before you go home on Friday you deliver what you promised.   But when you’re done clocking all your time, you put in 50 hours to get the project done.  That’s a 25% overrun, and your manager wants to know what happened and why you took so long.

There are a lot of things going on here – but the point I want to make is that there is a difference between an estimate and a target.  An estimate – “How many hours is this going to take?” – is very difficult to get right.  There are always unknown unknowns that enter in to make the total number of hours that something will take.  We are notoriously bad at making estimates.  There are a lot of reasons for that, but the fact remains that we are not really capable of making accurate estimates.  But “I’ll have that by Friday” is easier to say because you have flexibility in the amount of work it takes to hit that target.

But note well that an estimate is not a target.  A target is when you say “I’ll have that by Friday”.  Saying that on Monday morning is not the same thing as saying “It will take 40 hours to do”.  In fact, it’s a very, very different thing.  Saying “I’ll have that by Friday” actually means “I’ll do whatever it takes – put it however many hours it takes – to get this done by Friday.”  It might take 20 hours.  It might take 60 hours.  But you didn’t say anything about how many hours it would take, you gave the target point when it would be delivered.

So if you are a manager, recognize the difference between a target and an estimate.  If you are asking for an estimate, understand that software estimation is still something even the most seasoned developers do very poorly.  If you are asking for a target, realize you may be asking someone to put it a lot of hours to hit that target.  Or not – maybe they say “Friday” and it only takes half an hour.  Who can say for sure?  If Friday is good enough, then you shouldn’t care how many hours it ends up taking either way.

And the one thing you shouldn’t do is ask for an estimate, take it as a target, and then get upset when the developer hits the target but runs over on the hours. 

Targets are not estimates, and estimates are not targets.  Understand the difference, and you’ll have happier developers and happier managers.