Technology

Whither the Angel Developer?

We have the angel investor – a person who invests money at the very early stages of a new business. Often they believe strongly in the potential of the company, and while large return on their investment is possible, it isn’t always their sole motivation.

It seems to me that cash isn’t always the limiting factor that keeps someone from starting a new business these days, particularly in technology. I meet people every day with an idea for a software product or service they think people would want. Though they might like money to start such a business, they’d use it only to hire a developer to write the software – their actual barrier to pursuing the idea is not money, it’s technical expertise. So why not skip the whole cash part? It seems that deals coud be struck between developers and those with business ideas to develop the software in exchange for an early equity stake in the company. As with cash investment, it would take some due diligence by both parties, but I think it would work. Many developers already spend time altruistically writing open source software for the good of the community, so I find it fully believable that some would expend that same effort in an enterprising pursuit that could later yield big dividends. An Angel Developer.

Advertisement
General

Contracting – 1 Month and Counting

February 10th marked the first day I logged hours in my after-hours contracting with my previous employer. 29 days, 68 hours billed, three incredibly complicated screens done. (Where each screen involved managing probably a dozen different entities, passing data to pop-ups and back, and some fancy DOM manipulation using Javascript.) The real challenge in the app is not only understanding all the different entities involved, what they mean, and how their lifecycle is managed, but also creating a web application that behaves more like a desktop application. The validations, notifications, dynamic disabling of fields based on other fields, dynamic addition and subtraction of rows to a tier structure is all pretty intense.

In spite of averaging 2+ hours a day, including weekends, in addition to the day job, I feel fairly relaxed about it. It hasn’t interfered with my ability to enjoy myself nor my sleep. I’m into a routine – get up around 8, get to work by 9, work until 5 or 6 (depending on whether I take a working lunch), head to the gym (3-4 days a week), spend prime time doing what I like, spending time with my wife, playing Gran Turismo 4, etc. Sometimes I’ll put in some hours during prime time, but much of the time, I’ll dig in again after my wife is asleep (~10 pm). I’ve always been a night owl, so I’m very alert and there aren’t as many distractions, so it works out nicely. I’ll turn in for the night between 12 and 2, lather, rinse, and repeat.

The biggest challenge hasn’t been balancing business with pleasure, it’s been balancing this project with my other side projects. It’s challenging not to fall completely behind when you’re working 1/4 the hours of everyone else on a project. It helps that the time I spend is unencumbered by the typical overhead that comes with being a full-timer in the office, and I know I’m not expected to produce 8 hours work in 2 hours each day, but it’s something I put on myself. I do know that at a high level, my supplemental work has helped make some ambitious project deadlines a little more realistic. It looks like the other projects are on track, though, and I’m still convinced that the opportunity cost of the time I spend on them has made my work on them more productive and efficient.

Technology

I'm the development fairy

As mentioned before, I’ve been contracting back with my former employer as an outside-business-hours engagement. Hard to believe, but come tomorrow, I’ll have been at it for a month. Recently, there’s been an amusing development. My former co-workers discover some obscure nd ugly problem in the application we’re developing, and send me an email as they’re heading out the door to go home for the ngiht, asking me to look at it. I take a look at it that night, and by the time they come in the next morning, the problem’s fixed. Last night, the top issues were dynamic population of a select list using Javascript and IE completely flipping out when you try and populate a select list in a page from a pop-up.

I thought to myself how it would be nice to have my own development fairy for the day job. You leave in the afternoon frustrated with a problem, but when you come in the next morning, the problem is magically fixed. I guess that doesn’t sound too bad.

Java

JDO is Deprecated

It pains me to say it, but it’s true. I was as passionate as anyone that the JDO 2.0 spec, JSR 243, should be approved (and it was). A friend just asked me what persistence approach I’d recommend for new development – based on comments from the approval of the JDO spec, I just couldn’t recommend it. Unless something big changes in the Executive Committee, JDO will get one more release to define the migration path to EJB3, and then they pull the plug. Will your vendor still support you? Sure. Will the idea of JDO probably live on in some form? Absolutely.

It all depends on your goals, but if your goal is portability via standards compliance, almost any approach you’d choose right now for POJO Java persistence sets you up for a guaranteed migration to something else in the near future. JDO is becoming EJB3-related persistence, as is Hibernate and probably other open source ORM solutions, and the TopLink/Oracles of the world don’t really want your app to be portable in the first place. I recommended Hibernate – because it’s mature now, and is HEAVILY influencing the future of EJB3, far more than JDO is. As such, though it’s not standard now, the end EJB3 result is likely to be an easier migration from Hibernate than from JDO. Of course if you’re already using JDO, the fact that they’re offering a migration path makes it clear that you should stick with JDO until you choose to take that step to EJB3. I’m not saying to dump it for existing projects.

Is it an easy decision? By no means. But recognize that JDO’s funeral has already been planned. Barring a JCP revolution, coding new applications in JDO is building your app on a dead man walking.