Life After Xcode 4

I was recently asked what I thought the next generation of software development tools might hold in store. It was a great question.  I recently wrote a review of Xcode 4, Apple’s professional software development environment.  I’m still coming to terms with its changes. I didn’t have an answer for what comes next. What do I want my tool to do next?

I had to contemplate this a bit.  It seemed like I should have an answer for this question. Why did it catch me off guard?  Having thought about it, I realized the reason.  I was caught up in what the tools already do.  They do a lot.  In fact, there is so much going on that what I really want is simplification.  It’s counter-intuitive to think of simplification as a new feature.  Removing features doesn’t sound like advancement and adding more stuff adds complexity– or does it?  What if simplification just eliminates complexity, not capability?  Hmmm…

What Comes Next?

Let’s prognosticate.  A genre of tools exist that give users with non-professional level skills a means to create useful programs (or modules for existing applications, however you want to look at it). You can create some wickedly useful things with a program like FileMaker.  There are tools for creating simple games without low level knowledge.  Years ago there was a Mac application called Hypercard that people with limited programming ability could use to create interesting things. All of these types of programs leverage work done by highly skilled engineers to eliminate many levels of complexity for users.  With these tools and enough effort a user can produce sophisticated results with a far less steep learning curve.  My hunch is that we will see professional software development tools greatly expand what people can do with less programming knowledge.

If your development tool does more things for you, creating a useful program becomes more like assembling a kit from IKEA than actually producing the kit itself.  Today’s professionals already leverage a lot of work done by others to create software. For example, if I want to display a web page in my Mac application, I don’t have to write my own web browser.  The system provides code to do that. I just have to connect up with it.  Ten years ago or so I would have had to do that work.  There are lots of pre-fabricated solutions for many common problems that engineers use.  The bar for providing those features was once high and now it’s low.  This allows engineers to avoid constantly reinventing the wheel and focus on the next level.  There is always a next level.

It wasn’t very long ago that most of us had little ability to produce and distribute a professional looking video.  The widespread availability of digital cameras, editing software, and You-Tube have changed all that.  The bar of entry has dropped.  At the same time, the bar for professionals has risen.  It takes a lot more to thrill us at the theatre these days.  This same phenomenon is slowly taking shape in the production of software.  The bar is still high enough that most of the software you use was likely written by a professional.  That bar is going to drop enough to attract a larger pool of creators.

How Will This Happen?

Any way you look at it, creating something useful requires thought.  The problem now is that many great ideas occur in the heads of people who’ve mastered a domain that isn’t programming.  With the right tool automating work for them, they might be able to bring those ideas to fruition as real programs others may use.  For this to happen, it will require what programmers call a layer of abstraction.

Every time you use your computer you are dealing with many layers of abstraction.  Everything in a graphical user interface is a metaphor.  Windows, controls, icons, they all represent data.  You can take things to a lower level and open a terminal application to engage a different layer of abstraction. Keep burrowing down and eventually it’s all 1’s an 0’s.  Programming itself is full of layers of abstraction to hide complexity, simplify problems, and increase usability of code.

To allow more people to make useful programs will require development tools to write the difficult code for them.  Auto-generated code is not a new concept.  It’s just the ugly sibling most professionals would never use.  Historically, it’s been significantly less efficient than hand written code, comes with bulky dependencies, unpleasant limitations, and doesn’t play particularly well with other non-auto generated code.  But maybe this duck’s time to blossom into a swan has actually come.

The computing capacity of a modern personal computer has increased so much over days past that lack of efficiency is imperceptible for a huge number of tasks.  Dependent code coming from the system itself makes it easier and safer to share system wide.  Applications don’t need to build all of it into every application.  On the Mac, frameworks are particularly effective at supporting multiple versions, so older applications can continue to run using them while newer applications can take advantage of new features.  Much better design patterns are now common practice and with the power of Objective-C dynamic objects a lot of limitations and customization problems can be alleviated.  Work can be done to provide smart APIs for smooth integration.  I think we’re going to see our developer tools doing more with a graphical design interface and interviewing to generate application code.

This will drop the bar for a lot of tasks, but to really benefit users, the benefit of creating and using auto-generated parts of a program must be valuable enough for the pros to use it.  It’s not enough to simply lower the bar so more people can create software.  We want the pros to continue to thrill us.  If everyone can make their own apps by assembling pieces, the pros will want to create new pieces.  They will be glad to take work of their plates and use assembled pieces if they fit right in with their custom work without skipping a beat.

I recently spent time learning a game making code framework called Cocos2D.  You need to be a programmer to put that to good use.  But as I was working with it, I kept thinking that the whole process of creating a cool game could be graphically automated by someone with an application built on top of it. No need for the user to calculate trigonometric functions.  The app knows how to figure out rotation and trajectories.  No need to figure out loading sprites efficiently.  No need to understand playing audio. All of this could be set simply via a graphical user interface and the resulting game could be professional quality.  (Maybe there already is a tool to do this!)  It’s not hard to envision leaps like this for other types of applications.

Conclusion

True geeks will always want to get under the hood– as they should. That doesn’t mean we can’t give up more to the tools when it is useful to do so.  I’m betting we’re going to be doing that with many more things.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: