Some free advice to independent software contractors
I saw a post on Craigslist this morning for a software gig that made me shake my head.
"I have been outsourcing and modifying an Open Source project. There is about 50-100hrs of scoped development. Let me know your availability and rate."
Jobs like this one are poison that really puts all of the burden on your shoulders. I've been a consultant for several firms, and have lead delivery of many large and small projects. Here are a few tips to make it so that you maximize the shared risk in a project, maximize your revenue, and ensure the highest possible customer satisfaction.
Always Price on Your Own Estimates
You're the one doing the work, and you know how long it might take you to complete a given project. If a potential client hands you an amount of scope and a timeline (like the real-world example above), I would always request to assess the scope yourself and provide your own estimate before committing to anything. If the prospect is amenable to this, then it serves you well to give them a good faith estimate and some solutions in the case that your estimate is different. If the prospect is time sensitive, then work with them on adjusting the scope. If the scope is driving the project, then encourage them to consider an additional investment of time to ensure the completion of the full scope. Be willing to make concessions on your rate in these cases - flexibility from the client should be greeted mutually with your ability to discount your own rate.
If the client is not going to be flexible, then your best bet is to walk away or mitigate your risk through a more premium rate. Likely even in the latter case, a less saavy contractor will underbid you and find themselves in trouble. Better them than you.
Avoid Fixed Price/Fixed Time Projects
Clients love fixed price/fixed time projects. It removes almost all of their risk in the project and places you in the position of likely pulling quite a few late nights and reducing your hourly rate. Large consulting shops, particularly offshore ones - have the ability to enter into these arrangements and blend their rate accordingly to account for the need for additional resources in the case that the project falls behind schedule. For them, the cost of working a project beyond the deadline is significantly higher than it is to simply add more horsepower. Project management and technical oversight adds overhead in the project, and vendors are more than happy to not keep them on an engagement any longer than they need to.
That said, time and materials (hourly) arrangements are the best for the independent contractor. They place all of the burden to manage scope upon the client, and the client has to trust the vendor to report hours accordingly and honestly. Always aim for these projects, but do be honest with your client about hours and estimates around the cost of the engagement to them. Be willing to discount when your estimates are inaccurate.
Another option is a middle ground called target cost, but these types of projects are typically the result of significant trust between client and vendor. Simply put, you bill at your hourly rate for the agreed upon scope and any additional scope, and a discounted rate for defects and enhancements. This typically keeps both parties honest. Clients look to control scope for the same reasons they do in T&M, and it's in your interest to finish on time as to avoid continuing work at a discounted rate (when you could be taking on new projects at your standard rate).
Request Right of First Refusal
Clients are fickle. No matter how good your work is, when times are tight (as they are now), they will search for less expensive options. Many times when negotiating with clients, I have asked for right of first refusal in whatever contract we agree to as to ensure exclusivity. This makes you the preferred vendor and allows you to take all work that you are interested in before it is made available to competing contractors. Often times, this will require that you discount your rate. Additionally, this is usually only received well once you have established a track record of delivery with a client. But if you can negotiate this clause, it can go a long way to ensure you a consistent revenue stream and source of work.
At the end of the day, your client's satisfaction will be the best way to maintain business and build a stable relationship built on trust. Be open and flexible, but protect your position and never take on more risk than is neccessary, regardless of how desperately you want to land a gig.
Java Still Has Some Respect
A colleague sent along a note about how Dave Rosenberg feels that Sun Doesn't Respect Java. As I noted in a post from yesterday, I think there are some things to like about JAX-RS. But as a decent JEE architect, I have some thoughts on whether Java actually is exciting anymore.
- Has Java gotten boring? If you're a web developer, Java has always been like 6AM - too early to really be interesting, too late to convince you to go back to sleep;
- Java's middle tier absolutely blows anything else out of the water. I like LINQ, but comparables like ActiveRecord for RoR or PHPYii simply can't do the things that JPA can do;
- IoC/DI in Java, open source or JEE, is still better than anything anyone is doing today - Castle included.
Dave points out that the "write-once, run anywhere" paradigm may have lost out to virtualization. Call me when virtualization is native to all of the major OS's, Dave. Until then, the JVM is still the closest thing we have to a platform independent environment.
I've looked at the EE6 spec, and he's right though. Omitting things like Web Beans is certainly a disappointment. The fact that we still don't have great native dependency injection in the EE platform leaves us always falling back upon Spring. All of these things are rather frustrating.
JavaFX - just terrible. Adobe did it right with AIR, even if adoption is seemingly limited to hundreds of Twitter clients.
If Sun wants to start pushing the envelope instead of follwoing the leader - how about embracing a cloud computing platform through JEE? JAX-RS is promising, but why not unify the JAX-WS and JAX-RS spec to provide a single platform for all web-based SOA? At the very least, that would put them on par with WCF.
Unification of Java Weeds in a Standards Garden
After my post the other day in relation to building proper web UI architecture in PHP, my brain reverted to thinking about the complexities of web application development in Java and how in spite of standards, the amount of organic homegrown stuff that's out there has muddied the water to the extent that it's difficult to separate the wheat from the chaffe. Sun has tried it's darndest to follow the elephant and clean up behind it, but there is an increasingly sordid history of great ideas (Hibernate, Spring) that gained enough community momentum where Sun felt that these innovative platforms and their imitators should be unified behind a single standard. In fact, it's increasingly difficult to find parts of Java that were invented by Sun.
I haven't been architecting Java solutions for a living in nearly a year now, and last I checked the state of the world was more or less:
- EJB had assimilated Hibernate and other ORM solutions as something now called JPA, which was neccesary and useful to standardize;
- EJB had also taken elements of Spring to invert the once ubiquitous locator pattern and adopt dependency injection as the standard for satisfying collaborator relationships. Of course, the Sun solution aimed to solve specific problems in EJB, and had less interest in solving the more general need for standardization around DI-based application frameworks;
- JSF was crashing and burning in the web tier, with Gavin King once again trying to pick up the pieces and simplifying the entire stack through Web Beans.
So to distill it down - middleware in Java was actually a pleasurable place to work, and the web tier was still a torture chamber.
Note: I'm leaving Velocity, Struts, Spring, and Tapestry out of the mix here. That's not to say that there isn't value in some of these frameworks. Tapestry was architecturally sound but hinders rapid development. Struts and Spring both require siginificant configuration, and Velocity is...like Smarty for PHP. All of them did so many things differently that it would be difficult to standardize around any one of them. Additionally, the only one that could arguably be standardized within the exiting JEE stack is Spring - which attempts to solve many of the problems of front and middle-tier integrations.
Per my post from the other day, I really feel that the age of the server-based Web UI framework is dead. MVC will always be a necessity, but re-usable controls and architectures that try to solve all of the world's problems with different delivery mechanisms be it HTML or JSON are at a dead end - it's simply not scalable. So my attention turned to an article by James Strachan about JSR-311 and how he feels it could be the standard to solve much of the worlds problems. JSR-311 addresses the JAX-RS standard for delivery of RESTful services. This has long been needed from Sun given the narrow nature of the JAX-WS spec, but James has the right idea.
...Having had a horrid time using Tapestry and Hibernate together on some projects in the past, I'm kinda over the whole concept of server side UI web frameworks personally (I'm putting my flame-proof suite on now). I kinda think if you want to do complex rich web UIs, use wizards or complex flows, just use GWT or JavaScript on the client (or Flex/Flash for video or crazy highly graphical widgets) and keep the server side fairly simple and very RESTful....
So, I'm not the only crazy one out there. That's comforting. But is a standard that serves as the foundation for tools to deliver RESTful services the answer? From an architecture perspective, I've always been of the mindset that RESTful services, particular with its HTTP metaphors is just a DAO pattern exposed as services. This is a pretty fine grain for me, but as Seam in Java and LINQ in .Net are beginning to prove - the value of coarse grained business services as provided typically by Session Beans in EJB may be a bit overstated. So, does it make sense to build web frameworks that are really geared towards SaaS, and allow frameworks like Spring or Velocity or, hell even simple XSLT - take the helm when more traditional request-response mechanisms are needed?
And even more so, a cursory review of the JAX-RS doesn't really present any options for consuming the services produced by implementers. That's somewhat understandable given that the product is typically vanilla XML or JSON or Text or whatever. When I wrote my own RESTful service implementation using Spring a few years back, I made sure that XSD was attached and available when the service was XML. This made it easy to write JAXB clients if your consumer was another Java application. Slowing down development by forcing homogeneous consumers to parse the response as DOM seems like a likely outcome of not having SOME way of addressing this issue.
Taken together, I'm on board with the idea that JSR-311 could be a good foundation for a web framework that treats the client as being smart, rather than the dumb terminal approach of the past.
PHP Prado, Yii, and Building UI Architecture in the Right Place
I've been spending a minuscule amount of time as of late scrutinizing PHP frameworks - largely because it's so damn difficult to build anything that can be deployed to a cheap hosting provider in Java or .Net. In my travels these last few years, my conclusion is that Java is just terrible at handling web UI architecture and that the servlet architecture is horribly broken. But you already knew that.
ASP.Net is fascinating in that it really tries to port good classic MVP modeling to a web architecture. But we live in a world today that needs two models of web application development - one that focuses intently on transactional operations and can adhere to the infrastructure that ASP.Net or even Java Server Faces provide, or one that is totally dependent on the faclities of the browser. Where Microsoft and Sun/JBoss/OSS have gone totally off the deep end is in the latter case by trying to solve client side issues on the server.
So I looked at PHP Prado the other day, and saw that it's more or less a direct port of the ASP.Net architecture. Fair enough. I can't see how it can be performant or scale - it's taking the pig of ASP and adding a significant hassle in backing it with a scripting language. But as I dove deeper and tried to find out how it supported AJAX, I saw that it made the same mistakes that ASP and JSF had made by trying to adapt the server-supported client UI architecture into a model where the server really had very little to do with the presentation.
I'm now off and looking for a PHP framework that doesn't attempt to solve the problem in this way. Microsoft has already figured out that it's incredibly complicated to accomodate both paradigms of web development throug a UI architecture that was initially developed to run from the server and has built ASP.Net MVC and WCF to support a model where the coupling is much looser. Maybe someday, Java will get it (though I will cop to not knowing what people in the Spring world are doing, and they tend to be a bit ahead of the curve in these matters). I'm now looking at PHP Yii, and it looks like another dreaded rails-inspired framework. However, if it's not trying to boil the ocean with complex UI architecture and tell the browser to handle things as it may, perhaps I can be won over to the rails-religion yet.
Simplifying XML-based RESTful services in Elgg
elgg is a PHP-based social networking wonder that we've been using at Medullan for some internal stuff lately. One of my interests was to see what type of tooling could be built around it - desktop widgets, firefox extensions, etc. It appeared they had a RESTful API of sorts, but the service results were always rendered through the standard HTML view. Everything I found seemed to say I was stuck with this. Not so.
If you attach a querystring parameter to your request called view, elgg will output your RESTful service result to any of the supported formats - HTML, XML, JSON, FOAF, etc.
So if I have a method called "print" exposed as documented by elgg, I can have the result returned to me as XML very easily:
http://localhost:8080/elgg/pg/api/rest?method=print&view=xml