Make a business app without writing a single line of code

Writing a business app for iOS, Android and Windows Phone without writing a line of code. This is the challenge that a company seems to have set out to address. I took it for a quick spin, it looks impressive for a first start.

If you’ve been here before, you know that I always express skepticism when I encounter this kind of claim. But when someone like Scott Hanselman tweets it, then I pay attention and will give it a shot. That’s what I did and here is how it went.

I visited the site, followed the link to create an app, picked a template/example and simply accepted all defaults. I chose to download the source codes. Within about 3 minutes I had three apps downloaded to my mac. The web site looks clean, it’s easy to follow.

App Control panel
App Control panel

There’s an option to download the fully built and ready-to-go app.

Trigger app build process App's being prepared for download Download your app

When you install the app, you get something that is really basic but functioning.

login view

main view

I then loaded the iOS version on Xcode to take a look at the source code. Browsing around I saw a source tree that is reasonably well organised, clean, simple and straightforward. You see that it doesn’t have much feature. I wouldn’t call this a foundation to base anything evolved on, but the basic hierarchical navigation views are in place.

Sample app in Xcode

I tried to build from Xcode and straight away the code wouldn’t compile. I saw there were missing dependencies, could try to solve that manually but decided to use cocoapod for that (everybody does these days). Indeed the presence of podspec file was another give away. After refreshing the dependencies, the code still wouldn’t compile, the Test target failed. So I deleted the Test target, then the code runs. I couldn’t be bothered to spend much time on this.

There’s also Android and Windows app source codes available. I didn’t take time to go through those, but I expect they would be similar: basic structure, quick and easy, but not much feature to see. To be honest, the basic app structure created by Xcode would be much like what you get here, one benefit is that through the theme feature of the web site, it’s possible to make it a bit more proprietary and get going.

Brief summary

For a beta service, this looks like a good start. It certainly will help people who just need a decent looking prototype to get started. The concept of App Builder, aiming at people who don’t want to write code, seems to be in motion. I’m not sure how much success they’re getting, but it is worth checking them out regularly. There might be situations where even a professional developer would want to get something simple out quickly, particularly throwaway ephemeral apps that are not worth over-engineering. This one looks good for that kind of purpose. For more elaborate needs however, writing code is still going to win the day.

To write good code, you need to think carefully about what you’re trying to do, what the context is and what the constraints are, then design a solution that cater for those things.

This is really about mechanical sympathy

Damien Katz posted some interesting thoughts on C programming, compared with many popular ones.

Damien Katz blog post about C programming is interesting. It has a number of funny quotes, typical of programmers, any experienced developer would benefit from pondering them.

Here is the article: The Unreasonable Effectiveness of C


Tetris point is where everybody is making the same claims

I read a huge amount about information technology, of which I see a lot of open source code. The more you do that, the more you see something of a pop culture across the board. It’s just like fashion, everybody talks about the same thing. Everybody is (seemingly) doing the same thing. It should perhaps work a bit like the game of Tetris:

  • Our technology is built with performance and simplicity: strike!
  • My open source library is fast and lightweight: ka-t’ching!

If you never see anything else, it may be time to move on to something new.

Good essay by Bret Victor, but he’s got one thing wrong in the opening chapter

I read Bret Victor’s latest essay, it’s very good. But he started off by refuting a quote of Alan Perlis which goes like this: “To understand a program, you must become both the machine and the program.”, and Bret thinks this is a mistake. I think Bret got that argument wrong, he is misunderstanding the issue that Perlis is addressing.

I read Bret Victor’s latest essay, it’s very good. But he started off by refuting one argument, which I think he’s got the wrong end of.

In the opening section Bret quotes Alan Perlis as saying that “To understand a program, you must become both the machine and the program.”. Then Bret adds in the same sentence:

This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one

Yes, it is quite obvious that people aren’t machines, but that is besides the point. I think Bret got that argument completely wrong for a simple reason: if two persons don’t speak each other’s language, there is no common ground to hold meaningful discourse on. When a person writes a program, they are effectively engaging in a future discourse with a computing environment (computers, operating programs, and everything that defines the operating context of the program being written). So if this person has no idea what his/her writing (code here) could mean to the computer it is destined to run on, then the outcome is uncertain and bad things are more likely to happen. What makes programming difficult, to learn and/or practice, is the fact that people are dealing with infinitely more complexity than they think or assume that they are.

Alan Perlis wasn’t trying to be pedantic, which some people clearly are when they drivel on esoteric things in order to mystify others as a way to show off their skills and expertise. That is not what Alan Perlis was doing, Alan was simply saying that unless someone is truly aware of what  they are getting themselves yourself into, hence the metaphor of embodying those things, that person can be almost certain that bad things will happen. And that, I think was a sound judgment. Perhaps the prose could be different and more elaborate, elegant in the way that Bret himself writes, but that says nothing about the real content.

Learning about programming is difficult because the student (let’s call it that) has no idea what to expect. Some programming languages become popular because they simplify and reduce the amount of concept that the student needs to learn. Other programming environment, C language for example, are complex because virtually on each line one could be easily making several mistakes and it takes a long time to learn them all and become proficient with it.

So, the programming student is typically going to start off on a bias that is determined by the context where the learning is occurring. If the teacher isn’t good, the teaching will suffer and eventually that student will go off and spread misunderstanding further on. The complexity is compounded by all the human factors that typically add up over time. This isn’t anybody’s fault per se. It is a wicked problem, it starts off as a problem of appreciating the true mileage that lies ahead and how one’s own lung and leg capacity would fare in the journey, to use a sporting metaphor. I think that is What Alan Perlis was probably referring to and I think he was spot on. Bret is wrong in this case.

Having said the above, Bret’s essay is quite brilliant, a league above what we can regularly read on the topic. Kudos for his clarity of thought, and the generosity of spreading it out.

If you are into this topic, you would do very well to read Bret’s essay on his blog:

Getting serious about programming, I mean Clojure

If you read this blog then you probably know that I think that “laziness” is a good attribute for a programmer. Few things thrill me more than finding out that there’s code I don’t need to write. Scala is good, but it’s got too much Java in it and it’s not beautiful to read. Clojure however is just a superb language, and I like the way I don’t squirm at someone else’s code. ClojureScript is the icing on the cake, it makes end to end internet solution crafting a joy. I am not suggesting that other programming languages aren’t good or anything, I am only saying that Clojure has become my favourite programming language.

I’ve never been far away from programming over the years. Last three years definitely saw a significant change in my habits, instead of simply analysing the architecture of some newfangled technology I found myself spending more time and enjoying writing code. It used to be that, after a couple of lines I’d be already bored to tears and often moved on swiftly to something else. I didn’t care because it didn’t matter that I’d be an expert in a particular technology, I seldom claim to be an expert in one technology. When a user issue arose, I am usually able to do my bit or could count on someone who’s the programmer on the job.

When I decided to reorient my career, I went back to some earlier loves, being creative, try and crack difficult technology problems, build and ship solutions myself. One by one I opened up my archives looking for something useful, my exploratory paths took me to my university thesis dissertation: implementing TCP/IP stack on an X.25 network. I was shocked to see that my memory of that stuff is still fresh like it was yesterday, what a shame I didn’t carry on working on that stuff. Then, I realised that actually what I’m doing is only a continuation of those earlier efforts. So I thought, let’s find out what the cool kids are toying with and why they think it cool.

Rediscovering functional programming sort of reignited some long lost buzz. Over last years I learned (or re-learned) to program in OCaml, F#, Lua, Haskell, Erlang, Python, Scala and Clojure. Ruby and Rails framework have been with me since 2006 but they never really became a passion. Of all those languages, Clojure is the one that seriously grabbed my attention and retained it for a long stretch of time. I’m discovering the reason that happened every day.

Suddenly I started writing code by thinking naturally about how I would go about solving a problem, with little or no infrastructure stuff getting in the way. What’s more, some times I’d think of a problem and a solution direction, then imagined that someone must have already solved that, set out to find out and I’d usually come across a code that’d be just like I imagined it. I thought mathematics was the most beautiful thing I learned during my study years, I didn’t get a career in Finance but I didn’t realise that that subject would come back rushing in my life. With functional programming it is sort of happening, though I’ve not had to resort to anything complicated yet.

If you read this blog then you probably know that I think that “laziness” is a good attribute for a programmer. Few things thrill me more than finding out that there’s code I don’t need to write. Scala is good, but it’s got too much Java in it and it’s not beautiful to read. Clojure however is just a superb language, and I like the way I don’t squirm at someone else’s code. ClojureScript is the icing on the cake, it makes end to end internet solution crafting a joy.

I am not suggesting that other programming languages aren’t good or anything, I am only saying that Clojure has become my favourite programming language.

Java is the new Cobol, of course. How else can it be? Enter Eclipse Xtend.

Eclipse Xtend may be a response to Jetbrain’s Kotlin, definitely making it plain that Java isn’t cutting it when it comes to programmer productivity.

I just saw an announcement of a new programming language from none other than the Eclipse group, you know of the Java IDE fame. A very quick scan of this new language, called Xtend, it looks like they’ve borrowed a bit from Groovy, something from Scala and maybe something from CoffeeScript. The fact that this language is directly supported by Eclipse IDE is a huge advantage, and that may be to the detriment of Scala which still hasn’t got a great IDE support yet. I think this move by Eclipse may also be a preemptive strike against JetBrain’s Kotlin. If the community picks up on this then I expect initiatives like Redhat’s upcoming Ceylon programming to struggle in gaining any foothold.

I’ve been wanting to write a post on how I thought Java just wasn’t good for programmer productivity, seeing this announcement encouraged me to finally post it. I did something with JBoss Seam a few months back, took a step back to look at the code and thought to myself what a waste!. I can’t believe anyone in 2011 would want to create new code using JSF for example, it simply feels wrong.

From the moment that I renewed my focus on functional languages, I find pure Java code to be an eyesore, the web tooling around Java are simply atrocious compared to what you can do with functional languages like Ruby, Clojure or Scala. Clojure way well be the most elegant of the lot, I like it so much that I’m increasingly considering doing more hacking than I’ve done in years.

Competition is a good thing. But I’m wondering if Xtend is a more of a Groovy clone and if that could be such a good thing for the wider programmer community. I haven’t written a single line of code with Xtend yet, this is just a spontaneous reaction, in fact a post I had drafted about Java as the new Cobol, but refreshed in the light of this announcement by Eclipse.

The traditional IDEs should go on a “diet” program

Traditionally IDEs should go on a diet program, they are unnecessarily too heavy and fail to accomodate the rapid turnaround time they are intended to provide. The emergence of web browser based IDEs is probably going to help a lot.

These days I do a lot of rapid prototyping, turning around small but fully working apps fast is my equivalent of PowerPoint slides. As you do this, you realise just how much of a resource hog the integrated development environments (IDEs) have become (always have been?). And there is really no good excuse for this. Sure, computers are getting faster and cheaper, and the traditional IDEs seem intent to make sure you never realise the benefits of that.

I’ve worked with many popular IDEs over the years, the ones I’ve used most are Eclipse and IntelliJ IDEA, and Microsoft Visual Studio (memories of Powerbuilder and Borland IDE are still there). The one constant thing I’ve noticed with IDEs is that user waiting time is steady, it is getting longer in some cases, not shorter. Aside from code refactoring features there’s nothing fundamentally new to these tools. Somehow you always need the top of the range computer to run traditional IDEs, and if you’re running anything else at the same time such as a word processor, or a database then you might end up spending a lot of time waiting for your computer to give you control.

Why are traditional IDEs lagging behind (actually hindering) the performance gains afforded by the hardware evolution? I think one possible cause is that these IDEs are still failing to become truly modular. Various efforts to tune the IDE into understanding the user role remain too timid, you get a little less clutter on the toolbars and windows here and there, but the start/stop time and various frequent activities remain painfully slow, because the stuff is just too heavy for no particularly useful reason. This topic actually ties in to my rant about virtualisation still failing the desktop power user, more on that on another blog posting.

On the other hand, text editor centric IDEs are quite nippy. Take TextMate, Emacs, VI, you get to work much quicker and spend most of your time doing work rather than waiting for the tool to complete some task. These tools do offer code completion and search, what you really miss is perhaps the refactoring and interactive debugging capabilities. And I think those aspects are becoming less relevant, test-driven development in a good agile process makes debugging unnecessary for the best part of the development lifecycle. If these practices are combined with something like behaviour driven development increases the odds of producing good quality code. The programming language really helps if it’s less verbose, in that sense I’m starting to think of Java as the new Cobol really. Languages that are based on functional programming are such a tremendous help in thinking clearly, writing less code and spending less time with infrastructure stuff.

The emergence of web browser based IDEs such as Mozilla ACE might provide a serious challenge to the traditional IDEs, and that would be a good thing.

Programming language review whirlwind

Selecting a programming language in this day and age is actually fun. I had a lot of fun comparing the following languages and their eco-systems: Ruby, Erlang, Scala, Groovy, Haskell. I’ve come away with lots of new insights that I’d forgotten or overlooked. I think a practising hands-on software engineer or architect would gain a lot in endeavouring in this type of journey.

Every once in a while you get a chance to evaluate various technologies for their suitability to a job. I’ve reached one such time, and the task is about taking a fresh look at the programming language and platform for this particular project, pick the most adequate. I’d forgotten how much fun such a journey can actually be.

In this initiative, I got inevitably drawn on the popular functional languages that many in the open source community thrive on. I’m glad I got to do this, it made me realise that I was drifting away from some of my earlier and most consistent mantra: reducing waste, fighting off verbosity in the way we build solutions.

The languages that I’ve evaluated and compared in this initiative were: Ruby (and its ecosystem), Scala, Groovy, Python, Haskell, Erlang. Why didn’t I do this earlier? It’s simply crazy not to have done so earlier and often. I’ve now learned my lesson, I’ll be doing this regularly from now on.

When architecting solutions, writing ‘no code’ is the nirvana. This being the real-world, fighting off verbosity and tedious repetitive stuff is the most efficient way to solve problems. Functional languages provide the best platforms for addressing modern computing needs.

Information Systems Architect should write solid code, Part 2, how?

Code is the most efficient way to convey ideas to programmers. Architecture code should be embryonic, a starting point for a solution. Architecture principles help when they define some ground rules for composing solutions out of components, the boundaries and contexts of these compositions and the special conditions that should be guarded. All this can be expressed much faster in wireframe code, than in complicated text. If you can express architecture principles in diagrams and text, be sure to also express them in solid code. I call this say it in code.

In an earlier post, I stated that an Architect should write solid code. I’ve also tweeted about this, pointing out that an IT architect who doesn’t code cannot be trusted. To illustrate my point, I chose a fictitious test case organisation, Trotters, where Kermit works as an Architect. I described some of the consequences when someone like Kermit is far removed from code. If you are interested in this discussion but haven’t read my earlier post, I invite you to do so here.

In this post I will discuss some of the ways that Kermit could write code to make the architecture practice more effective in his organisation.

To begin with, here are some more (bold) statements – I could always prove the points at a later stage.

  • If you can draw diagrams, you could also provide framing code base that realise the diagram
  • If you cannot create code representative of the diagrams that you are drawing, then either:
    • you are unsure how to do this (no further comment on that), or
    • your ideas are not fully fleshed out yet (so you are not done), or
    • you are reluctant to get into the details, for some reason
    • In any case, this is a problem.

Writing wireframe code goes much faster than writing long documents, and it harmonises interpretation much more efficiently. Text and diagrams leave a lot of room for interpretation, every programmer is likely to interpret things his/her own singular way.

Code is the most efficient way to convey ideas to programmers. Architecture code should be embryonic, a starting point for a solution. Architecture principles help when they define some ground rules for composing solutions out of components, the boundaries and contexts of these compositions and the special conditions that should be guarded. All this can be expressed much faster in wireframe code, than in complicated text.

How should Kermit go about this?

To simplify I will focus on web application as the solution domain for Trotters. Kermit and the team are working with object-oriented (OO) design and development concepts, they standardise on UML notation. They could be programming on Java or .NET platform, that doesn’t matter here.

Here is a simple guidance for Kermit:

  • UML supports drawing component diagrams. Kermit has probably designed a layered architecture diagram. Therefore, Kermit can create equivalent UML artefacts in code by designing classes for relevant components using the most appropriate realisation path.
  • Components in a layered architecture will typically interact via interfaces. Kermit can create (mostly one-to-one) interface classes between each connection points in the architecture. OO design skills are necessary to do this right. This is a first test of Kermit’s ability to say it in code. This can be further refined when for example using a concept such as design by contract, of which ample free resources can be found on the Internet
  • Boundary conditions and constraints: modern programming languages like C# or Java offer an array of features to deal with constraints. (similar concepts are fairly trivial in other languages) In addition, boundary conditions and constraints can be expressed in test harnesses, in turn included in the codebase as part of a continuous integration setup. Such productivity measures are invaluable and they often teach teams aspects of the solutions that might not be trivial, let alone described in text documents.
  • Enforcing architecture: this aspect is made trivial when considering the development environments (IDEs) available to programmers these days. These IDEs ship (or can be complemented) with code analysis and validation tools. The most recurrent patterns and errors can typically be verified with little or no effort, thanks to the richness of the validation rules that are available for these tools. An organisation like Trotters, as discussed in part 1, is typically weak in this area, and that is a shame.

Once expressed in code, the following become enabled:

  • Efficient two-way feedback on the architecture: programmers can immediately spot any issues and raise them for resolution with the architect. Kermit’s ability to communicate in code will come in handy, as he is able to grasp implementation issues quickly and can improve his design in the process
  • Enforcing architecture principles: nearly every modern programming environment offer tools for validating code and testing boundary conditions.
  • Platform constraints are immediately brought to light: with architecture code, architects and programmers are immediately confronted with infrastructure constraints. This makes it possible to analyse the situation, convey feedback quickly to all stakeholders before anything is really built. This helps in reducing gaps in expectations across all groups.
  • Guarding against basic mistakes or repetitions: there are elements that are typically common to every solution in a given business domain. There is no value in painstakingly recreating such elements, as that would only expose Trotters to unnecessary mistakes (typing, errors or omissions due to human factors, learning the hard way).

An easy argument could be to claim that Kermit, as an architect, does not have enough time to delve into programming details. Another easy argument would be to claim that should Kermit delve in code, he would be overstepping his role (micro-managing?), or that the programmers’ creativity could be hampered. Such arguments are easy to bring up, it is very tempting when one knows nothing better to do. But such approach is misguided, in most cases. First of all, I argue that an architect can write solid code much faster than he/she can create useful documents with legible text and diagrams. A second reason why I think this is misguided, is that the tools and techniques available today are amazingly powerful and simple to use, not using them to their true potential equates to disservice to the organisation. As a way to illustrate this last point, I’ll take a totally unrelated example: as I look over the shoulder of some people using Microsoft Word, I’m often amazed to see how they go through the pain of manually formatting documents by inserting spaces and page breaks. These people don’t seem to be aware of features that were in the product since version 2.0! (the first I’ve used). That is the point. And this example is actually nothing compared to the inefficiencies caused by programmers and architects enforcing early 90’s work processes with 2010 generation of tools and techniques.

To summarise, if you can express architecture principles in diagrams and text, be sure to also express them in solid code to reduce communication gaps. I call this: say it in code. Users typically don’t relate to design documents (architecture is part of design in this context). Often case, design documents would pass approval gates without users noticing faults or shortcomings in them. And this should be expected, precisely because users hire architects for their solution skills and experience. Architects shouldn’t expect that users could validate solution architecture, which is what normally happens a lot – again I’m using the term users in a broad context here. On the other hand, once solutions are shown to users, they can more effectively provide meaningful feedback. So, Architects should express technical solutions in solution, and code is the closest form that can be less immune to human interpretation induce deviations.

So far, I’ve focused on the application architecture aspect of the Architect role, in my simplified view. Looking at the broader architect role, including business analysis and infrastructure design, saying it in code will involve other aspects that I won’t analyse too much here for a number of reasons. This posting is already quite long, I’m still trying to keep it short enough yet complete in its illustration. In future postings, I will tackle these other architect roles.

In the next instalment I will explore the limits of this concept. If I get more time, I will develop the concept further for Trotters by showing specific examples of the type of code that Kermit would be writing to help his organisation (eat your own dog food idea).

GO, a case for a new programming language

With the advent of Google Go, there’s a renewed debate on whether we needed a new programming language. Actually a case can be made, for a niche player or an organisation with the right momentum to develop and maintain a new programming language.

No programming language will ever be fit for all purposes. Microsoft, among others, understood this and catered for it as they created C# and many variants of CLR compliant languages. As the technology platforms evolve, it should be natural to factor in the lessons learned and try a new approach.

In fact many already maintain Domain Specific Languages (DSL) without necessarily thinking of it as a programming language. Martin Fowler, @martinfowler, talked eloquently about the subject on his blog. In the Java world for example, template engines provide a really powerful method for organisations to become even more productive. With the right architecture, a lot of development and testing time can be cut if developers and architects can set up a good infrastructure to leverage the power of these tools.

If anyone can come up with a new programming language and be successful with it, Google can. When Chrome came out we were wondering the same thing, whether we really needed a new web browser. Now then? Another really interesting thing about Google GO is that the architects made a very clever choice by making it easy to learn for C or C++ programmers. This lowers the learning curve significantly, even good Java developers will be able to pick up GO quickly. Some of the concepts of Google GO seem to be inspired from Objective C, another big win there because Objective C has some really elegant constructs.

So there you GO, building on proven concepts, just like C# did when it came out, Google is bound to deliver the goods. I expect this language to grow fast because it can potentially leverage existing libraries. The adoption will be easier when appropriate tooling start to emerge. I foresee an approach like Google Web Toolkit, as a path to building bridges towards existing language platforms or runtime engines. If the compiler is as efficient as advertised, GO might just give Google a kind of unifying language that helps reduce software engineering effort by taking away deployment platform concerns. Microsoft is busy with a similar approach, their Oslo project and LINQ efforts are indications of the sort of goal that can be sought. I can’t way to start playing with it a bit.