Dave Winer: Why apps are not the future:The great thing about the web is linking. I don’t care how ugly it looks and how pretty your app is, if I can’t link in and out of your world, it’s not even close to a replacement for the web.Let’s set aside one thing right away. The browser is an app. Text editors, outliners, and web servers are apps. And, without them, there’s no web at all.Somebody has to write these things. That implies APIs and more tools that are also apps. It implies an entire ecosystem of apps that are absolutely vital to the web.I think Dave is...

Every time you hit a mobile network, it slows your users down and introduces another point of failure. So when you're designing your application, you need to take advantage of every opportunity to omit needless requests.Parse's philosophy is to help make this easier by providing standard ways to reduce network requests. One example is caching queries, which lets you avoid resending requests you've already sent. Another example, which we've launched in the most recent version of the Parse SDK, is include functionality, inspired by the Ruby on Rails :include option.When you have relation...

Much of the tension in product development and interface design comes from trying to balance the obvious, the easy, and the possible. Figuring out which things go in which bucket is critical to fully understanding how to make something useful. Shouldn’t everything be obvious? Unless you’re making a product that just does one thing – like a paperclip, for example – everything won’t be obvious. You have to make tough calls about what needs to be obvious, what should be easy, and what should be possible. The more things something (a product, a feature, a screen,...

7Share6inShareAgile methodology was supposed to be a solution to solve all of our problems. But it looks like it’s not. Some issues appear when companies start to implement Agile in their organizations. A research has been done on seventeen companies using Agile methodology (People over processes: Key people challenges in Agile Development). Authors chose nine of the most often reported issues. I’d like to focus on four, in my opinion, most important.#1 Developer fear caused by transparency of skill deficienciesThe Progress of each team member’s work is usually rep...

How many times have you tried to get something done that needed some touch of originality and creativity and yet got that annoying mind block which is manifested by blank stares, scratching and biting on anything in reach? “all the damn time” I hear?As preconditions to be creative, one should know something well while having the utmost focus on it. Someone who knows little about aerodynamics can’t come up with the idea for next concord. And focus has two aspects: knowing a specified area well (focus area) and being able to bring most of those neurons to work on it. How do yo...

Release early, release often is a philosophy where you release the product as soon as possible and rapidly iterate it to perfection by listening to your customers. A polished release, on the other hand is where your product, in its initial version is solid, lacks obvious bugs and has just enough features to satisfy a majority of your consumers. Most software companies adopt either one of this and that choice is not superficial. In fact, it roots down to the heart of the company’s ideologies.Before you launch your next big product, website, app, read this and decide which side you are on...

If you are a good developer and you’ve worked in bad organizations, you often have ideas to improve the process.  The famous Joel Test is a collection of 12 such ideas.  Some of these ideas have universal acceptance within the software industry (say, using source control), while others might be slightly more controversial (TDD).  But for any particular methodology, whether it is universally accepted or only “mostly” accepted, there are a multitude of organizations which don’t employ them.  There are many, many shops that do big bang testi...

Good software trumps elaborate code. And unfortunately, you can’t usually have both. The real world has deadlines and ship dates. It’s a game of pick two:Ship on timeShip with elaborate codeShip with a fantastic productAlmost always, you should pick the first and the last when you’re building software applications for users (if you’re building API’s or open source libraries for other developers, then it’s a different story). Too often I have seen developers, when struck with a brilliant idea, no matter how small, plunk away at building an elaborat...