This is a quick thought. But a pattern has been on my mind lately. A lot of leaders want their employees to listen to them and learn from them.
However, when that same leader is questioned by their employees, they often don’t want to have to justify decisions. Do this “because I told you to.”
Why not let your ideas stand on their own merit? If a subordinate wants to engage in discussing the value of an idea, that sounds like an opportunity to teach them (or learn from them if they are right).
Recently, my job has changed a bit. I’ll probably write about that in a post coming up, but for now it suffices to say that I’m definitely spending more time than usual thinking about entire projects and all aspects of the project. Naturally that has me thinking about process more. I have always tended to prefer Agile methodologies, and the Lean flavors in particular.
However, I didn’t feel that I really had a solid background in the lean parts. While I’ve understood the processes and motions and studied Lean manufacturing in college, some of the motivations and subtleties are tied to a deeper understanding. I feel like I needed to spend some time reading the best works on the subject. Practical experience on lean teams is great, but I wanted more.
With that in mind, I reached out to Rick Simmons (@simmons3k). I used to intern for Rick way back in my college days and we keep up and discuss software, Agile from time to time. Rick is an Agile Coach for Rally, and at one time helped implement and improve Agile processes at Constant Contact. Needless to say, he’s an expert in the area. Rick was kind of enough to give me a list of Lean books that he recommended, and I got the idea to publish the list as a post with his permission.
As I read some of these, I intend to follow up with more posts about what specific lessons I took away from each one. Feel free to follow up with your thoughts in the comments below.
If you’re interested in seeing what the signers of the agile manifesto are up to these days, I’ve compiled a list with twitter and blog links below. If you use twitter lists, I’ve created on here.
If you have any corrections, please post in the comments below.
PhoneGap (now becoming known as the Apache Cordova project) is commonly thought of as a cross-platform mobile development solution. While true, I think it’s best to think of PhoneGap as modernzr for the mobile web.
The W3 is working on standards for web sites to be able to access specific hardware features. These common hardware features were first prominent in mobile, but are coming back to laptops via tablets and hybrids. Feature examples are GPS, Camera, Motion Sensors, Network Sensors. Also, mobile has popularized the idea of system maintained contact lists and other information that is now available (with proper permissions) to all apps.
The runtime in your application is a native app which hosts a native browser control, and that browser control is pointed at a local directory you include in the app with html. And the javascript has access to some os specific features that are exposed to javascript.
When those standards are in place, mobile web sites will be able to fulfill most of the promise of native applications. This is why Steve Jobs didn’t want to build an app store in the beginning, and both RIM and Microsoft have been pushing html/css as 1st class ways for building apps.
In this new world with device access standards, only special circumstances like intense 3d graphics should require native code in a c-like language.
But this isn’t the world. Those standards aren’t in place. So PhoneGap fills that gap (any guesses about the name?). And it has the added benefit of supporting the app store distribution model, where mobile web apps require the user to bookmark the page to their homescreen.
Most cross-platform apps get knocked for performance reasons. Sure PhoneGap apps are html and javascript, but javascript engines are improving a lot these days, and you can always use plugins to push key pieces of your application into the native arena. Plugins in PhoneGap allow you to write native code (ie Objective-C on iOS) that is exposed to the javascript in your application.
Also, cross platform frameworks are usually criticized for their look and feel. In PhoneGap, you’re using html and css, a platform that we’ve been working to style for a very long time (in tech terms). I think this fact explains some of the reasons that companies like facebook and linkedin use html heavily in their frameworks.
If you’re interested in getting started in PhoneGap, I recently reviewed a book I recommend to get started. It’s a couple versions back now, but it covers things conceptually well, and it’s a nice companion to the docs.
Not every application is a fit for PhoneGap. There are reasons to go native. But I think that for basic data goes in / data comes out type of applications, It’s a great way to start. And getting good at writing single page style apps with heavy javascript will push you in the direction the web is already going.
Creating Vicinity Buzz naturally involved working with a the APIs of social networks. That information seemed worth sharing for those of you interested in writing any type of application that would integrate with a social network.
Developer Documentation
Any of the social networking sites you probably want to integrate with have developer api’s that are well documented. Here’s the starting points for a variety of services:
All of these APIs are best used with JSON. If you’re not familiar, you can read up at json.org. It’s the notation for serialization of javascript objects, and object literals.
Where To Make the Call From
If you are working in a standard web page, you could call the api from document.ready (assuming you are using jquery). This is the approach I take on hoolihan.net, my personal homepage. There is a twitter feed on the right side.
If you have a bit more of an application, you may want to look at one of the many javascript frameworks that help you route events to actions. These are frameworks like backbone, knockout, spine, etc. There are also commercial variants like kendo, dojo, and sencha.
jQueryMobile is commonly paired with PhoneGap, and in that scenario, using something like backbone is a bit tricky. You may want to bring in a template binding library, but avoid routing.
Binding
jQuery.templates was one of the first good javascript template binders that I’m aware of, but there are now many different options. In the jQuery world, most of the momentum seems aimed at jsrender. Recently I’ve considered bring in knockout and only using the binding part, but I’m not far enough in to evaluate that direction.
API Keys
Unless you’re using the most basic parts of the API, you’ll probably need to register your app and get an API key. It’s a token that identifies your application. In the event of API abuse (too many calls, etc), they have information to contact you and analytics around the issue.
Open Authentication
This is a big topic, but if your application wants to use a social network to identify your users, this is possible via open authentication. If you are interested in this, get started here.
What Do You Think?
Are there any particular areas of the APIs that you’d like to see more detail about? Any conceptual parts that would warrant their own post? Let me know what you think below.
If you’re a developer, you’d probably have to have spent the last couple of years in a coma to not notice a trend towards simpler tools, but I want to write a bit about the changing tides in software architecture because I think there is more below the surface.
Around 3-5 years ago was the peak of an era that could be called “the Church of Martin Fowler”. Big software design patterns were in. All of our domains were to be modeled, everything needed a service class, and interface oriented design was all the rage.
Before anyone gets upset that I’m disparaging Martin’s name, let me see the man is a genius. And like any object of worship, terrible things have been done in his name, whether or not he asked for them. In other words, many of these patterns were applied to pieces of software that did not fit the patterns.
But I’m less interested in debating the past and more interesting in discussing where we are now. Rails was one of the first blows against large, complicated software creation. Today, many in the ruby community talk about the bloat of rails, preferring frameworks like padrino, sinatra, etc. Most new languages build super light weight web frameworks first. Look at compojure for clojure, or express for node. Personally, I happen to really like Sinatra, and have used it for a handful of sites that I help with in my personal time.
Does this mean software patterns are dead? Should we all move back to php (which may have been ahead of it’s time)?
I think there is something else going on, namely that tools are addressing a different level of the problem. Pragmatic programmers (literally, not referring to the publisher) often site the adage “use the tool for the job”. Combined with the long cited un*x philosophy that its tools “do one thing well” we can see a pattern emerging. Sites can do one thing well, expose their interactions via http, and build a system of of smaller systems and their interactions.
I don’t think the tools are moving away from complexity for simplicity’s sake, I think they are moving to a new way of dealing with complexity. The tools (sinatra, express, nancy) are designed to create subsystems and you are expected to stitch the subsystems into the complex systems.
It’s like SOA, with http as the service bus, and more explicit dependency bindings.
I think that’s an important distinction. Enterprise architects look at some of these simpler tools and feel that they are toys for smaller sites. But those that embrace them are saying back to that architect “why have tools that provide safety and assimilation across 50 developer product teams, when you can avoid having one big project with 50 developers?” And that’s not a bad question. There are some real analogies to Steve Yegge’s recent software conservatism vs liberalism post.
I’m not taking the position that one side is always right. These are approaches, and any approach tends to have contexts that are it’s sweet spot. But I think this new trend is massively misunderstood. Similar to how many folks think that NOSQL means “No SQL”, instead of “not only sql”.
One question is, can the vendors catch up? Or will this only be an open source trend? Microsoft cleaned up it’s web stack with ASP.Net MVC, but it’s still on the heavy side in comparison to the direction that the open source community is heading. Does Microsoft have the capability to embrace something the size of Nancy? Some would argue web pages (razor) was that answer, but it seems to lack the first class prioritization of routing and http that the open source frameworks do.
Thinking back, it’s easy to wonder why this didn’t happen sooner because of SOA. Maybe this is what the SOA community missed, that better (and simpler) tools were needed to build at the new level that SOA asked the developer to target.
Software companies, particularly those that sell large enterprise software, want to get customers into their CRM systems and into the sales pipeline quickly so that regional sales folks can follow up. Pricing and other aspects of licensing are often customized to the industry and other needs of the customer.
While those arguments seem valid, I think it’s foolish to put up barriers that keep customers away. In the course of evaluating software, often times you just want a classification. What price range is the product and what is the licensing model (one time? yearly?) so that I can compare it with other software.
Let’s go through some of the common arguments:
No one pays that price, so why lead with it?
Who pays full price for a car? Yet I can look up MSRP on the manufacturer’s site, cars.com, or on any number of other web sites. It helps me determine that a Hyundai Tiburon is competing with a Mitsubishi Eclipse, not with a Porsche.
Only enterprise customers are using these types of software, and those purchasing managers know how to get in touch with big ISVs.
First, that’s just not true. Take Oracle for example. If only Enterprise customers matter, then why is it available on Amazon’s EC2 model? Oracle has migration tools from MySQL, various licensing models, and all aimed at bringing smaller customers into using Oracle 11g. So why not let them see what the tiers are?
Second, Enterprise customers are often collaborating with service and consulting firms (like mine), why can’t we get a quick view of pricing in order to make recommendations? Sometimes we want to partner with an ISV, but often times, there is no need. So if I sign on to your sales form, then I’m getting called about purchasing your product when I’ll never purchase it.
This is a really important point. You might expect the consultant to put the leg work in anyway. If this is a software selection process, then yes, we’re expected to deal with the sales team if necessary in order to get 100% accurate licensing cost. But on a project with a tight deadline where a consultant is recommending many different tools to put together and do the job, they will often not dig that far into the possibilities. So they are making recommendations to an Enterprise customer based on things like: old pricing, forum posts, and reputation. All because the vendor won’t post a pricing sheet. I’d rather post a price matrix with higher prices with some large clauses like “negotiable” than have people running around deciding on my software based on guesses.
There are drastically different programs available for startups and we don’t want to cause confusion
This one has some merit, but I still say post a price sheet. Put a big link at the top for other paths. For instance, new companies going with Microsoft technology have the bizspark program available. Above a SQL Server price sheet, I would put a big bold link that says something like “If your company is new, click here to learn how you may be eligible for free Microsoft licensed products for several years”.
Our licensing model is too complicated.
This is the only reason I see valid. Some of the models (take IBMs PVU pricing) probably just complicate things too much to post a simple matrix. That said, if you’ve reached that point, I would consider simplifying.
So what about my company, we don’t post any prices for our services. (This is my personal blog, I’m not speaking for the company, yada yada yada…). That said, custom professional services is much different than being an ISV. Price matters, but we are usually evaluated on our ability to do a job, and how well we will do it. Additionally, there are so many variables and different models for how we right contracts, and it’s usually per the clients preferred model, that pricing sheets are rather useless.
But it’s a fair point that some ISVs may see themselves that way. I just think it’s a mistake. At the end of the day, developers and architects are looking to classify your product by price and features. Are you going to provide them that info? Or is a forum post / tweet going to provide them some info that may or may not be correct? You decide.
You may already know this, in which case you ran across it randomly, or are the kind of developer that reads specs. But if you haven’t run across this, prepare for a face-palm moment wondering why you didn’t know this years ago.
Using a uri like the following tells the browser to get the content over whatever protocol the current document was fetched from.
Think of all the little annoying server side script you’ve written to determine the protocol based on the request variables in order to avoid security warnings. Never again. Enjoy.
There is a lot of talk around 3d printing these days, and what it will do for manufacturing. How it can democratize the creation of products and move innovation back into a cottage industry alongside big R&D departments. Once again, individuals will be a key creation of inventions, holding patents and other forms of intellectual property.
While this is interesting, there is a bigger picture to be excited for. What does life look like when this technology is commoditized and ubiquitous. Working in technology, there is a pattern that I think will hold true for 3d printing: the technology and hardware lose value, while content is king.
If you haven’t seen 3d printing, check this out:
Look at music. MP3 players ushered in a revolution. Now they barely exist. Who buys an mp3 player? It’s a feature of your computer, tv, game console, phone, car. Lots of devices can play mp3s. The money is in the marketplace (itunes), and the content (publishers and artists). Publishers are complaining and have been hurting because they didn’t adapt. With manufacturing taken out of the equation, the barrier to entry it lower. Record labels now compete on the ability to promote artists, content and merchandise, as well as general business acumen. Some will adapt and survive.
So what happens when 3d printing is everywhere? The barrier to entry for general merchandise is lower. Barbie™ is now just content. She is a license. I don’t go to a big box store and buy a plastic doll that was shipped across the country. I buy a license to print a doll for my daughter from some “iTunes for everything” store, and it prints. So now, Mattel’s advantage over the makers of a generic blonde doll (with unrealistic proportions) will be their ability to market and innovate a brand and culture behind the doll. Meaning that packaging, distribution channels and manufacturing are no longer a competitive advantage. Sure, they have a head start with branding, but they haven’t exactly been breaking their backs fending off competitors, have they. But what about when this digital license store for everything is selling a Barbie license for $4.99 and a model made by a home hobbyist that comes with a link to some youtube stories about the doll for $.99?
Which is why companies like Mattel would accept this shift in the first place. Knockoffs or pirated plans for their designs will be on the market before real designs are anyway. Just like music, the big product companies will get dragged into this business by the inertia of the technology.
In this version, a couple of interesting questions come up. Who owns that license store? It’s way too early to guess, but if I had to put money down now, I’d say Apple and Amazon are the leading contenders for seeing this far into the future. Being cloud content providers, they will be on top of the ball realizing that I want to carry these licenses with me, especially once the printer is a commodity.
Which brings up some other interesting areas: maintenance, travel and license enforcement.
I should never need to buy my daughter another doll if it breaks, because I can just reprint one. Thinking of disposable things, how is there recurring value. Once I buy the license to a razor, I never need to buy one again.
For that matter, what stops you from printing razors for your neighborhood? What is the DRM model like for a trivial thing? And who believes there wouldn’t be an open-source razor that was good enough.
Certainly I like the fact that I don’t need to store all these things. Assuming we can print almost anything, then I don’t have a closet full of toilet-paper, I just print a roll when I need it. Think of all the things in your house you don’t need to store, from seasonal tools to disposable goods.
The idea I really love is travel. If my phone/tablet/whatever is my wallet (near field payment) and stores my licenses, then I can travel with just the clothes on my back. Each hotel room would have it’s own 3d printer and I have my preferred razor, toothbrush, and entire wardrobe available.
Highway truck travel drastically reduces in a world where I only need the basics “inks” (raw materials like polymers, metals, cotton) for my 3d printer. My town is now full of service providers and social locations, not big box retailers. Personal travel for errands goes away. The virtual workplace is realistic or more than just information workers, center employees and data researchers. Certainly the remote access of this is huge. Imagine a specialized implant needed in a remote medical center. Or repair parts needed on a space station. Imagine the difference to the Apollo 13 crew if they had a 3d printer.
A lot of this view of the world relies on the ability to easily recycle these materials back into those raw materials (inks). Assuming that, then some things may go away. For instance, if the power used to recycle and reprint an item of clothing is less than the power to wash clothes, then clothes washers go away. You would wear an outfit until done, then put it in a recycling bin. And you don’t need a closet, you just have a license to a variety of designs. If clothes are always new, then will the stigma of wearing the same outfit go away. Will people find 2 or 3 favorite outfits and simply rotate those.
This new view of the world of things is very interesting to me. On one hand it has a utilitarian view, where we can have much less stuff around us on a regular basis, and people can more easily live wherever they want. On the other hand, it doesn’t have the cold feel of many utilitarian views of the future, because of the freedom and ease of design, redesign and distribution. If the printer can use almost any material and the recycling can keep efficiency pace, it could really be a stunning new world where we have real ways of dealing with scarcity. Materials are used more efficiently in this manner, and products only need to exist during small windows of time. An for an even bigger change, imagine what happens the minute organic material can be printed in this, namely food and replacement organs.
A couple of months ago, I finished reading Eric Ries’The Lean Startup. It got me to thinking about startups and small projects I’ve been a part of in the past.
In particular, I think of a social site for readers that I was apart of that failed. I think of the the end, where I was trying to make the case to launch something and let users drive the feature list. What I find really frustrating is that I did such a poor job of communicating that at the time. Reading the book, I hear a much better way of emphasizing the point of customer feedback loops. The minimum viable product with hypothesis and user testing driving the next steps; it has so much value. Additionally, that movement has a number of successful followers to their name, so they have credibility with their message. Timing and other market factors may have doomed us anyway, but I can’t help but thinking of what could have been different armed with some of that information at the time.
The other part of the book that really resonates with me is how hard successful startups are. People are so afraid of there idea being stolen. In the book, Eric Ries suggests that you try to have someone steal your idea (it’s hard to do). He’s right. If someone actually wants to steal your idea, at least it validates that other people think it’s a good idea.
I get approached by people with startup ideas a lot, looking for programmers who want to work for equity. For young developers with the time, I think they should get involved, it’s a great way to learn the realities of business and to get some extra experience. But beware of how much of a longshot it is to get the product successfully to market. It has to be a good idea, successfully built, successfully marketed, and fill a timely need. Miss any of those categories, and you probably won’t do much.
I’m not suggesting people avoid startups. They are a great learning experience and some of them work out. But go in with your eyes open to the amount of work you have in front of you. And be discriminatory about where you choose to invest your time. Are the others involved willing to put in the same effort you are? Will this new organization be capable of all of the things needed to be done to launch a product?
My advice for evaluating an idea: run a set of books for the project (meaning keep accounting). If you’re working for equity, keep track of time anyway and what you could have been paid at your regular rate to do that work. How long will it take for the project to pay that back? That question opens a lot of eyes. Say what you will about money as a measuring tool, but it’s the standard for all projects and companies. It’s relatively objective, and very compatible with math. The same can’t be said of a subjective goal like “let’s take over the XYZ market.” Presumably, you have your day job because you make someone more money than you cost them. If you can’t say the same of your startup project within the first year, then your project doesn’t even have the ROI of your “boring old day job” (you may love your job, my point here is that people thing of startups as high risk / high ROI and that may not be the case). Every time you sit down to put more into the project, you’re saying that you will get that back in cash on the other end. Is that true, or are you kidding yourself?
There can be other reasons to do a startup. I’ll use a personal recent example. I built VicinityBuzz, and iOS application around Social geo-search (also coming soon to Android and WP7). It’s been slow out of the gate so far, but I’m hopeful that some of the new features coming in the next update and some marketing ideas I have will help. Regardless, I’m certainly a long way from paying myself back for the time I put in. But I have been working in cutting edge technologies more and mobile is a real focus. I knew even if the project never paid for itself that it was valuable time learning and to put the project into my portfolio of work. I went in with those realistic expectations, but try really hard to exceed them.
If there is intended to be a single message of this post, it is to apply measurable goals to your projects, and evaluate and pivot your direction as often as reasonbale. If I had to boil down the message of the book to one sentence, that would be it.