Mar 24, 2013

Sustainable Web Development

This post will be a bit of a detour from my regular material - I normally take an interest mainly in technical topics, but these past couple of years, I have taken an increasing interest in the business side of things, and today I'm ready to share some thoughts about a sustainable business model for software development.

When I say "sustainable", I'm referring to development practices that can help keep a business competitive, both in terms of performance (time and price) and quality - as well as talent retention.

The key, in my opinion, is to invest in optimizations up front, to decrease turn-around time, increase quality - and keep developers free from distractions, focused on goals that matter to the client (things they can see and understand) and above all, happy.

Here is an illustration that demonstrates the basic principle:

In timeline A, we go straight to work on a set of features being built as part of a project for a client. In the alternate timeline B, we instead start by optimizing in various ways, which in terms of time and cost is an immediate loss - as you can see, features A and B are completed behind timeline A. However, long-term, this loss turns into an overall win.

Now, we may not achieve the "edge" shown on the illustration after a single project - it may take multiple projects to get there. But if you invest in the right optimizations, you will get there eventually.

Here are some of the basic optimizations we can do:

  • Educate Your Team: Give developers the time they need to learn new technologies and more modern patterns that produce better results in less time.
  • Take Ownership: Encourage developers to take ownership of the technology they've selected - give them time to contribute to open-source projects you use. This benefits both you and the community.
  • Evaluate New Technology: When new libraries and tools become available, have your team check them out early. New development tools, automated building and deployment tools, databases - even a new programming language, if it comes to that. Keep an eye on the direction the world is moving - know where it's going to go early, and don't get left in the dust.
  • Create Solutions: Avoid short-term, stop-gap patches - these either come back and bite you in the ass later, or you end up repeating the same patches on your next project.
  • Take Charge: If there is no existing solution for a recurring problem identified by a developer, maybe the opportunity has come for you to demonstrate some community leadership and create that missing solution.
  • Modular Development: Build for reuse whenever possible - it takes longer to build a feature as a reusable module, so don't blindly build modules for everything. But always weigh the benefits of being able to ship a particular feature in very little time, improve it's quality over time, and resell it on future projects - versus building a lesser version of that feature, and building it repeatedly.

Saving time is not the only long-term benefit of following these principles - some additional long-term benefits may include:

  • Side Effects: Often, more modern technologies and tools are not only faster to work with, but produce increased quality in the form of positive side-effects - slicker UI details without any extra effort, increased security, or easy access to other little "nice to have" features; things that add to the client's perception of quality, and meets the increasing expectations of end users.
  • Slimmer Codebases: Typically, working with better libraries means writing less code - having less code to maintain typically makes it easier to change a feature; it is usually easier to modify 100 lines of simple, elegant code, than 500 lines of tangled, complex code. Your clients will perceive you as being more flexible and helpful, when you deliver (to them) seemingly small changes without any push back, a substantial bill, or delayed delivery.
  • Consistency: When each project is built using the same modules, libraries and tools - and when those are well-known to the entire team, we can delivery consistent (or increasing) quality in a predictable time-frame, every time.
  • Expertise: Becoming an authority on something, or becoming a vendor of something others use, is good for the company's image - and it's good for the team morale.
  • Focus: Accept that you can't be good at everything - you will earn more of a reputation for delivering great solutions on time, than you will for being capable (but at best average) at everything.
    There is no such thing as a client who will hire you to do "everything" - every client needs "something".
  • Flexibiliy: On a more technical (and perhaps more personal) note, I highly recommend you urge your team to avoid dependencies whenever feasible - having the freedom to replace a single component (without throwing away an entire framework) means you can make incremental overall improvements.

Ultimately, all of these things also have the added benefit of increasing developer happiness, which is key to retaining talent in the organization.

Keep in mind that human attention cannot be purchased - you can pay people to do what you want, but only until they find somebody else who will pay them to do what they want. You cannot pay people to care - since you're buying their time, making sure they are interested and invested in what they're doing may actually be more important to you as a business owner, than precisely what they're doing.

Fortunately, cultivating sustainable development also generally leads to more excited or enthusiastic developers.

After all, new tools and technologies in the area of software development are rarely toys - software development is not video games. Unless it is video games, but then maybe that's what you want. I digress. If your developers are adamant about newer tools and technologies, there is usually a reason: with a little up-front investment, we can do things faster and better, while also having more fun! :-)

And yes, I like to have fun - I'm not ashamed of it. It so happens that fun for me is usually about delivering better software in less time. Win for you as a business owner, win for your clients, and win (and more fun) for me!

Of course, the benefits of what I propose here can be hard to measure - but it's easy to measure when a company is not doing well, so maybe what you need is a better long-term strategy?

If you've been working your ass off for years, if your clients think you're too expensive, if your best developers walk, or if you're losing potential clients to the competition - chances are you haven't yet invested in technology that is truly sustainable for your business.

Mar 19, 2013

Hello "Web Languages", Where's the "Web"?

I just have to get this off my chest.

How come the leading "web languages" are all languages that don't have a single web-specific feature?

Before flames start coming out of your eyes, let me explain what I mean.

Every major "web language", including PHP, JavaScript, Ruby and Python, has APIs and frameworks that make them useful for web-development. But all of those languages actually belong to various families of classical programming languages, and haven't actually added anything to the languages over time, that make them more suitable for web-development as such.

As a web-developer, and given how web-development is practically synonymous with software-development in this day and age, I find it disappointing that so little effort has been put into making the languages themselves more web-friendly.

I should preface by saying that this is not intended to be a language comparison - I'm only looking at the aspects that relate directly to web-development.

Let's take a look at some of the most popular "web" features of the leading most popular "web language", namely PHP:

  • Inlining code fragments in documents: this is commonly thought of as one of the things that make PHP a "web" language - that you can embed pieces of code between HTML/XML tags. But in actuality, everything outside of the <?php ?> tags is just seen as implicit echo statements. Markup is merely text to the PHP interpreter. Hence, this has nothing to do with any web-technology as such.
  • $_GET, $_POST, $_SERVER: these are merely global variables - other languages have their own APIs providing access to query fragments, post-data and server-variables, this just happen to be exposed as superglobals in PHP.
  • XML, XSL, DOM, JSON, etc. - these web-technologies are simply integrated into the language as run-times, exposed to you via APIs. They weren't even implemented in the language itself, but in C - so we rely on a language that is by most people's definition explicitly not a "web language" for the real underlying support for web-technologies. In other words, the web-related APIs are not a feature of the language, but of the external run-time libraries that are available for the language.
  • OpenSSL, stream-wrappers, HTTP, FTP, etc. - most other languages have support for streams in some form or other - some languages had streams before there was Internet. And again, these are features that ship as part of the platform - they're not language features.
  • Multi-tenancy: because PHP processes aren't static, we can host hundreds of sites on the same server. Scripts only take up resources for an instant while processing a request - each site/app does not occupy memory or threads while waiting for a request. This appears to be a big reason why more hosting companies like to host PHP more than, say, Ruby or Node - because they execute as a static process. In actuality though, Apache (not PHP) is responsible for the multi-tenancy, which also applies to (for example) PERL scripts. It could be implemented in other languages, by starting with an HTTP server that is designed for multi-tenancy, e.g. sandboxing modules for security. So this is another platform feature, and not a language feature.

The bottom line, is that the world's most popular web-languages do not in fact have any web-features.

Note that I'm only using PHP as a case example here - you can apply the same arguments to Ruby, Python or JavaScript. I'm not trying to knock on PHP, or claim that PHP (or any other language) is "unsuitable" for web-applications - that would be ridiculous, especially given that I build web-applications (primarily) with PHP for a living, and I might not go as far as to say that I love it, but as languages go, I really like PHP a lot.

But I'm informed enough to know that PHP, like most other mainstream languages, merely borrows concepts from classical, general-purpose programming languages - and as such, by definition, the language should be considered a general-purpose language.

Let's contrast that with a language that was designed specifically for web-applications - here's a summary of some of the language-features of a fairly new language called Opa:

  • JavaScript: Since JavaScript is the most prevalent client-side language technology, Opa can transparently cross-compile Opa code to JavaScript, automatically slice client/server-concerns, and integrate JavaScript-versions of Opa code with the client-side.
  • HTML/XML: Because the heart of the web is HTML (and XML) it is not merely supported via an API or as objects, but as literal values. A portion of Opa syntax is HTML syntax - and it's not just being interpreted as strings, but closely integrated with the DOM on the client-side.
  • REST/SOAP: Web APIs are increasingly available and increasingly necessary - the Opa language facilitates transparent integration of web-services, allowing you program against remote services as you would any other local API.
  • Databases: Because web-applications by definition are multi-user applications, they are almost always backed by a database. Because this is such as central requirement to web-applications, Opa has language-level support for binding variables directly to database objects, as well as as for querying those objects.

In other words, working with technologies like HTML, CSS, DOM, XML and JavaScript is not a detour from the language itself - it's part of it.

Opa is also a compiled language, it's a functional language (which poses it's own barriers for most people with a classical OOP background) and every application is a static process - so this platform has drawbacks, too, but that's beyond the scope of this discussion, which only deals with the aspect of language.

tech·nol·o·gy (noun)
"The application of scientific knowledge for practical purposes, esp. in industry."
I'm not religious when it comes to programming languages. Technology as such is merely ideas and tools we create to make our lives easier, and every technology, without exceptions will one day be replaced. Because technology is only useful until it is no longer practical.

Even technology such as The Wheel will one day become a fun historical artifact that people will look back at with giggles.

Software is still a fart in the grand perspective of the timeline of History. How pompous would it be to assume that a little thing like a programming language is here to stay indefinitely?

The ideas and concepts in mainstream languages that dominate the web-industry, really weren't designed for the web - can general-purpose programming languages keep up indefinitely by merely adding another API or another general-purpose language feature?

I hope this is encouragement to start looking more critically at the languages we use for web-development.