Tag Archives: linkedin

The Pendulum of Architecture

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.

ISV Pricing

The other day I tweeted about something that has bothered me for a while:

[tweet http://twitter.com/thoolihan/status/236099028545318912]

I feel like it’s worth explaining my problem.

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:

  1. 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.

  2. 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.

  3. 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”.

  4. 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.

Simple URI Tip for HTML

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.

<script src="//platform.twitter.com/widgets.js"></script>

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.

One warning… don’t do this in phonegap.

More detail, and links to rfcs at stackoverflow.

Lessons of a Failed Startup(s)

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.

Boiling the Ocean (or Attempting to Keep Up With Tech)

I was asked by a fellow developer how I keep up to date on the variety of technologies that I’m expected to understand when doing my job. I intended to write a short answer, and generate a blog post as a longer answer. I got this idea from Scott Hanselman, who in his talks about productivity mentions saving keystrokes, and the idea that when you answer a question for someone, you should share that in a way that is useful to you and others. With that in mind, here’s the advice I would give if you find yourself taking on a job that requires a broad knowledge of the technology and software.

Question: Somebody in your position obviously needs to understand a lot of technologies to be able to pick the best solution for a project. How do you approach learning and having an understanding of all the new stuff that is constantly coming out? Obviously you can’t sit down and learn every tiny detail, but do you just obtain a high level understanding of how things work and then flush out the details once you start a project in a technology that you’ve never used before?

I use Google Reader a lot, I just checked and I have 121 rss/atom feeds going into it. They are not all work related, and it’s not like I read every article. But I star stuff I want to read, or put it in Instapaper and then go back to it. I try to read a mix of updates on what I already know and interesting things about what I don’t.

As for how to learn and retain, and relate technology, that is a harder question. I’d love to tell you that you just get a high level exposure first and then fill in the details when needed, but my mind doesn’t work that way. I hated classes like Systems Analysis in college that only talked about systems in generic terms, because I couldn’t relate those terms to specific examples.

My own take is that in the beginning of your career, you just have to learn practical skills and learn the tools you work with well. When you start wanting to learn about systems and being able to evaluate, compare, select, recommend, etc, then you pick up as follows:

Let’s say I’ve never used a database, and I’m assigned to work on a project that will use Ruby on Rails and PostgreSQL. Take the on the job time to learn the tool as well as you can, focusing on the aspects you need for your job. Where possible, try to understand and separate product names / features from conceptual names / features. In this example, that means understanding what database and schema mean in generic terms, and why they mean different things in the PostgreSQL than they do in some other products (like Oracle or SQL Server). Spend a little bit of off time playing around with an easily attainable (usually open source) alternative. Spend a night or two doing those same types of tasks in MySQL. You’re not looking to be a dba, just doing similar tasks as to what you do. Finally, talk to people who use other products and compare. This works great with products that are hard to get a hold of because of cost, etc. In this example, talk to an Oracle DBA or App Developer. What features do they like about their product that would prevent them from switching. If you don’t know one, ask the question online. Quora, LinkedIn, Twitter are all great places for this kind of question.

At this point, you’re out of work time (so not counting your project time working with PostgreSQL because you would have done that anyway) is 4-6 hours on MySQL and maybe another hour in conversation. But you should have a really good idea of the concepts surrounding relational databases.And you should know what the different projects compete on in that arena and what some of their strengths and weaknesses. If you spend time away from that field and come back in, you should have the conceptual understanding and just need to buff up on the implementation details and latest trends.

Two other quick pieces of advice. First – After getting the practical experience on a type of tool, read the Wikipedia page. Most pages are at most a 15 min read and they lay out the purpose and strategy behind any tool type, and usually list the major players in that area. Second – Try to keep personal opinion from having to much sway. We all prefer different tools, but every tool can be criticized. That’s important to do, and know it’s weakness, but don’t dismiss the tool outright. They were built for a reason, a context. And many of the weaknesses relate to some tradeoff the programmers / vendor made that has a good reason behind it.