Architectural mood swings

Currently, Apple is under a lot of pressure to add Flash to the iPhone and iPad. Since, according to Adobe (http://www.adobe.com/products/player_census/flashplayer/), 99% of internet-enabled PC's have Flash installed, it's fair to say that Flash is currently a well-adopted platform. And I guess that about 70% of the online video-content is Flash. But, no Flash for iPad. It's a CPU hog and old technology, according to Steve (http://www.pcworld.com/ar...obs_bad_mouths_flash.html). Is he right? Well... a bit.

The problem here isn't Flash, or at least wasn't. 1) It's the lack of Flash-like features in native browser technologies such as HTML that should have been there. 2) It's the fact that HTML isn't a very good RIA-platform.

Why is YouTube using Flash for displaying movies? Because HTML didn't support it natively. Why is it that a lot of RIA apps are built in Flash or Silverlight? Because it's much easier to do than a RIA app in HTML and therefore you get better results. If you don't believe me, take a look at the Silverlight-version beta of Bing Maps. It's not a coincidence either that Google Street View is Flash. Ever tried building something like that in HTML?

I see a lot of change in the RIA world. HTML 5 supports video and a canvas, making it a lot easier to create animation, transitions, and video-based websites and thus deprecating the use of Flash for a lot of cases in websites that use Flash for that right now. But, the dark side of it is that it's a very premature technology. Not all browsers support it. Developers around the world still need to understand how to work with it. HTML 5 isn't done yet. And most importantly: it won't support all RIA cases.

With these things in mind, I think the following will happen in the next 3 to 5 years: HTML 5 will replace flash for video in the browser and cases where Flash was used for fluid animation and font embedding. Technologies such as Flash and Silverlight will be used more and more outside the browser (Adobe Air for example) or standalone in the browser for standalone connected applications instead of integration with HTML.

And for what it’s worth: Although it has some implications, overall, I think that’s a good thing.

Building software on a budget is never an ideal situation. You are forced to make a trade-off between quality and functionality. You cannot have both or you will go over budget.

Most of the time, quality is forgotten and the budget is used for more functionality. The problem with this approach is that more functionality does not always helps you get the job done better. Roughly 80% of the time, you are using 20% of the functionality. Another problem is that forgetting quality almost always leads to going over budget, because buggy software needs to be fixed.

You should find and build that 20% core functionality first and make sure it meets your quality criteria. It will keep you within budget and won’t clutter future release schedules with bug fixing old releases.

A lot of line-of-business software automates a previously physical process. For example: project planning used to be a process on the white board and paper schedules, but nowadays this is done with software. Planning a project can therefor be done faster, cheaper and better.

An anti-pattern of line-of-business software development is developing unneeded software. It seems like a great idea and software is used to spawn the new business opportunity. The process and business case are forgotten. The risk here is that the software won't match your expectations because there is no cohesion between the software and the underlying process.

So, if you want to be safe: set up a business case, define the goals, define the process and be sure it works. Use software to support the process instead of being the process and dodge a lot of frustrations.

With the launch of the iPhone 3G, along came the launch of the SDK and the App Store. Since then, the iPhone developers community is growing rapidly and so is their frustration about the position they are in. This is because they had to agree with an NDA, which states it's prohibited to talk about code, whatsoever. No tutorials, no forums, no code samples. Nothing.

Now, one of the cool thing about developing applications in general these days, is that we have access to the internet as a resource for help. We can find code samples and forums to help us with our problems and challenges. We can talk about it on IRC channels or write blog posts with tips and tricks. With practically all other platforms, this is not a problem. With the iPhone SDK, it is.

Why would Apple do such a thing? With the SDK being in beta, it made perfect sense. But now the SDK is available to everyone, as long as you agree to the SDK, which is just one click. I understand Apple is a company which has a patent on secrecy, but this is just plain stupid. For a healthy developers ecosystem, you need an online comminity these days.

It's another example of the dualism of Apple. The iPhone is a great device. The Operating System is outstanding. The platform and SDK is way ahead of it's time. But still, there is a software lock-in (iTunes), a too controlled doployment channel (App Store), limitations in the software you may distribute and now the NDA.

Developers around the globe are uniting on a website initiated by a developer and twitter-user on this website: http://fuckingnda.com

They're about to just ignore the NDA and set up an iPhone internet portal. Because this is what Apple once used in their commercials:

Here's to the crazy ones, the misfits, the rebels, the troublemakers, the round pegs in the square holes... the ones who see things differently -- they're not fond of rules... You can quote them, disagree with them, glorify or vilify them, but the only thing you can't do is ignore them because they change things... they push the human race forward, and while some may see them as the crazy ones, we see genius, because the ones who are crazy enough to think that they can change the world, are the ones who do.

Now that C# 3.0 and .NET 3.5 are out, Microsoft is planning the next versions already. One of them is C# 4.0. Channel9 has a nice video, where the C# design team is introduced and talks about what we can expect with the next version of C#. Click to watch (silverlight/moonlight needed).

Highlights:

• Concurrency - Today we have processors with 4 cores. Within a year we'll have 8 or 16 cores. In the future we might have 256 cores or even more. Our software isn't ready for that. Microsoft already introduced us to the Parallel Framework which will extend the existing System.Threading model. But the C# team is going to include some changes too. Not to include a threading system, but to enable threading teams to create better API's. One of the things they talked about is "Method Purity", which means that a method does not access or modify anything but local variables for example. This makes threading easier since pure methods can run on its own. For this we'll get immutability supports, which is more than just lock an object entirely, but providing ways to identify something as immutable, even if some values can be adjusted, for example.
• Dynamic support - With the DLR and IronPython .NET was introduced to the dynamic world. But interoperability between static and dynamic languages isn't at a level Microsoft wants it to be. For this, C# will get features to cope with dynamic languages. C# won't become a dynamic language, but since the new .NET framework will get notion of a dynamic dispatch, static and dynamic .NET can coexists in C# 4.0.

There is some more stuff, but those two will most likely become the topics of debate. To get more details, watch the video.