Navoty

Still unhappy w/ the Blog Situation

I’m trying to think what I want Navoty to get out of its company blog. We had a hand made one, but didn’t allow for comments. This was largely due to fears over handling eventually (hopefully…) getting Dugg or Reddit’d, causing us to cache everything aggressively.

So it became more of a mouthpiece than a place to foster discussion. That’s fine, so we moved to Tumblr, which meant all of our scalability problems wouldn’t be our problem.

That said, it still doesn’t allow much for conversations, which is half of the reason I like to write posts (it’s fun to get the OMG YOU’RE SO WRONG posts). So I’m trying to think of what to do with it.

Further, the Tumblr solution is a little frustrating because I have to decide where I’d like to post. If something seems too self-righteous or angry or inflammatory, I don’t want to put it on our corporate blog. Then again, that’s probably 75% of my posts.

I thought about using Yahoo Pipes to put together all of our workers’ blogs and then just letting people subscribe, but that still doesn’t give people a place where they can all talk.

I think I might end up changing our blog link on www.navoty.com to a dropdown that independently links to our blogs. In addition, if you thought our posts were just the coolest thing ever, I could still put together a Yahoo Pipe so you could subscribe collectively to all Navoty’s known blogs. 

Just something else to put on the todo list.

 -terry 

2 years ago

Saving time and money with the Internets

One thing that old-school employers often overlook is the location of their developers. While they dictate dress codes, email protocols, lunch hours, time off, it’s just a given that the workers should be in the office from (at least) 9-5, Monday through Friday. 

This has several costs. One of the obvious ones is office space. Another is employee time. Sure, you’re only making them work 40 hours a week, but they’re commuting for 20-90 minutes, each way, each day. That can be an extra 15 hours a week, and it’s not time relaxing. It’s usually sitting in traffic.

Beyond the time it costs employees, gas prices, toll prices, car maintenance, etc. all weigh in. So what you’re paying the employee for their time gets thinned out by commute costs.  

While it sounds like I’m just talking about regular workers, the same goes for consultants. We try to save money, both for ourselves and for our clients, by telecommuting extensively.

We’ve got an internal chat server (we use Campfire), a project management suite (Basecamp), subversion, religiously use IM, and when we really need to talk, we use Skype.

Occasionally there’s no way around going to a client site, but for everything else we try to avoid unnecessary travel. It’s expensive, and we think that we’re most productive where we’re comfortable - at home.  

2 years ago

One man QA monster

I don’t like turning over critical software to people without tests. While my method of testing has evolved (manual -> a few people -> reluctant unit testing -> embracing RSpec), I’ve agreed with the necessity since the beginning.

While I have a lot of agile/lean friends who go all out on test-first, it’s just not my style. I’m not saying there’s anything wrong with it, it’s just a way of thinking that I don’t appreciate. I generally write a few hundred lines of code, then write about twice as much test code a few days later.

Well, I’ve decided I’m going to try something new. No testing (automated, at least), as much as I can avoid, except on Fridays. And on Fridays, I’ll be writing no new features, just tests. One of the things that I love about writing tests is it requires that I critically evaluate every line of code, and I find that doing it after I’ve lost the my train of thought usually yields more criticism (a good thing). 

Also, I hate starting into big new features on Fridays. It’s not fun, and it’s hard to get invested into anything when you know you’re going to stop working for a few days. This is not to say I don’t enjoy coding new features; I have hobbies beyond programming.

Since I usually work on really small teams (1-3 people), I think this will work out well. It forces code reviews (which not everybody likes, but I think yield great code), and gives me a time where I can write tests without peeking onto the backlog. 

I’ll check back in a few weeks to talk about how it’s going.

 -terry

2 years ago

Response Times

Aiming to improve performance for a client’s Java application, we’ve downloaded and tried out a few profilers. None of the ones we’ve tried out are free, but they had pretty enough screenshots to compel us to download them. After downloading and trying to run each of them, we’d be prompted for a key of some sort, which the sites will provide to you for free (though they expire after 8, 10, or 15 days).

So at 8pm Jeremiah signs up for Yourkit. At 8:45 I sign up for JProfiler (I had to get the whole tomcat/maven/eclipse stack downloaded and going first). At 8:50 I’ve got JProfiler running, with the temporary key. At 9PM Jeremiah is still waiting for his Yourkit key. Out of boredom, he signs up for JProfiler too.

5 minutes later, Jeremiah gets his JProfiler key, and starts using it. At this point we’d been so impressed with JProfiler and had been given enough time to play with it that Yourkit has no chance at getting our money.

While that’s a somewhat extreme version of response times, I think it’s a theme that’s everywhere. If your site loads too slowly, users will get distracted or seek alternatives. If we respond to clients too slowly, they’ll find other people who will respond faster. Quality and comprehensiveness are important virtues in consulting, but responsiveness is often overlooked.

Whenever I get an email, even if I don’t have the answer for the questions, I’ll generally respond within 5 minutes: “Hey, I got your email. I’ll look into this and get back to you by .” It lets clients know that we’re paying attention to them, that we’re not too busy to look into their needs, and that it’s easy to talk to an actual person.

-terry

2 years ago

Arguing is good. Not obnoxious.

Well, mostly. I argued with my mother-in-law today about some punctuation on a sign, and was just doing it to be obnoxious. But that’s not the kind of arguing I’m talking about.

When you’re writing software, there’s a good bit of subjectivity as far as methods and quality go. From which design patterns to use, to how a method is coded, to where a method’s placed, to the colors put on the splash screen, to the number of toppings on the company bought pizza, to the font picked for the menus, and on and on. If you have 2 people trying to pick, you’ll probably have at least 7 solutions in the room. Each new person brings up the number of solutions and variations exponentially.

This isn’t bad; it’s brilliant. As long as people can keep their feelings off the table and argue about the ideas and the different benefits and pains that each brings, if you can reach a happy consensus with everybody, odds are you’ve got a good thing going. Software design will be better. Colors will make more sense. Pizza will be more tasty.

It’s important not to get too personally attached to the ideas, because once they become personal and you treat them as reflections of yourself, attacking the idea becomes a personal attack. Suddenly, arguing about what’s best for the product becomes a pissing contest, and it’s one everybody wants to get out of as quickly as possible.

Arguments with lots of personally-involved feelings yield camels instead of horses. It takes the worst part of each idea, eliminates all consistency and beauty, introduces things that nobody but the feature’s authors care about, and creates a product that begs to be put out of its misery.

I’d rather argue and get a mustang than shy away from conflict and get something that spits at me when I push it too hard.

-terry 2 years ago

Not every process is a BPEL process

There are 3 opinions of BPEL: I hate it, I love it, What is BPEL?

For those of you in the “What is BPEL?” category, here is a brief synopsis. If you’ve heard the buzz around web services, service oriented architecture, etc., then you have probably at least heard of BPEL. BPEL stands for Business Process Execution Language. It is a standard for expressing (you guessed it) business processes in XML. It’s on its second version (BPEL 2.0) but don’t let that fool you in to thinking that it’s a mature standard. Currently there are several implementations of the standard, but I’m going to focus on the one I’m most familiar with, Oracle’s SOA Suite which is part of their Fusion Middleware. The SOA Suite contains more than just their BPEL process manager and I have so much to say about this suite in general, I’m sure I’ll devote a post to each component somewhere down the line.

The people that love Oracle’s BPEL Process Manager tout its many cool features:

1. Drag and Drop service orchestration
2. Enhanced visibility and tracking into your processes
3. Human Workflow
4. Quick Development time

All of these things are there, and if used in appropriate situations, they work well. What they aren’t telling you is the many problems that come along with this in the real world, and why people hate it:

1. It is XML based, making it slow and memory intensive
2. It currently requires an Oracle Database
3. It has a manual recovery ‘feature’ that will swallow your instances without notice.
4. Unit testing is impossible
5. Migrating through environments is difficult

If you have a truly service oriented architecture, then your long running business processes with inevitably use many different services and orchestrating these things through a home grown solution will take time and be difficult to manage. This is where BPEL shines. It can be kicked off by a JMS message, wait for a manager’s approval, escalate to the CEO after 2 weeks, then send a request to multiple external vendors for a price estimate, and return the lowest price that is returned within 10 minutes. All the while seamlessly tracking whatever variables you want to track, firing notifications, and giving you real time visibility every step of way.

If you have lazy programmers who love BPEL, it can also be used. This is where it fails miserably, allowing them to drag and drop together a short running process that calls a database, transforms data and sticks it in another database. The problem with this second scenario is that this IS NOT a candidate for BPEL. This is a disaster waiting to happen in your production environment, wastefully using resources, constantly getting stuck in the manual recovery queue, and with instances finishing much too quickly to get any benefit from BPEL’s strong points.

If you and your developers learn the appropriate places for BPEL, long running business processes that require service orchestration, and stay away from the quick and dirty uses, BPEL can help you.

-jeremiah

2 years ago