Great Lakes MotorSports

Month: Julius, 2012

My Software Toolsets

There’s really 3 major software stack categories that I find myself working in these days (well, more like 2.1 really, as it’s special as you’ll see). Thought I’d do a quick rundown on them after a couple recent discussions on development software. I’ve also read a number of articles and many forum questions from people that can’t possibly imagine the need for more than one (which is, of course, their favorite).

I’m currently spending most of my days in Java. That’s to be expected when working at Java shops! It’s a good solid language, with great libraries, and great (well, other than Apple’s, which is finally getting better now) virtual machines for cross-platform compatibility. The cross-platform stuff really does work. It’s an exceptionally rare occasion when I do something that isn’t cross-platform compatible. Even then, the majority of the time I find a way to make it compatible eventually (as in “I finally find a library routine that does what I originally wrote myself to call to the OS”). Most of the development time is in the Swing arena, since it’s primarily desktop apps and I dislike adding third party utilities unless necessary. Web side it’s in JSF, for the same reason as Swing on the desktop side. It’s all solid, reliable stuff. Not flashy perhaps, but gets the job done without the drama of going to a full-blown JEE app. Being able to drag and drop libraries/code between desktop and web side is also great. No real ugly surprises anywhere. One place where I have stepped outside of the pure Sun/Oracle environment is to add Clojure to my standard bag of tricks. It’s a really well done language, and running on the JVM makes it very useful. I’m not one to rewrite all kinds of crazy stuff in it though, I keep it to things that really make sense. In this case, it’s some occasional experimentation with ideas via the REPL and doing some of my more complex mathematical code. Really good IDEs are available as well. Eclipse is a bit bloated these days, but is still a good choice. Overall I prefer Netbeans right now as it’s still pretty fast and supports nearly everything I’ve ever wanted. All in all, a very good stack for common business use, especially where the OS may not be standard across desktops.

My .Net usage has been fairly limited, mostly just some quick updates on web sites that others have done, plus a couple mobile apps back the bad old days of CE, and a handful of small desktop apps over the years (including some recently). I’ve run into some weird library issues over the years, but other than that it’s also a very solid platform. C# is my favorite generic language in the family, but I’ve worked with the VB side as well. F# is also handy (for the same reasons as Clojure on the JVM), but just doesn’t fit me quite as well. Desktop, CLI, and web apps are all well supported here. The Visual Studio IDE is certainly usable, but I find it a bit clunky compared to Netbeans. With the current rate of improvement though, it may well surpass Netbeans in a couple years. I’m expecting to be doing more work in this stack in the future.

– Other (ADW Modula-2, MASM32, project specific & domain specific (SQL, etc))
Then, of course is my “random stack”. Actually just a collection of other pieces of development software that I still find myself using occasionally. C++ (via gcc) falls into this category even though my usage is pretty rare these days. I really haven’t had any time to work on the C++ based open source project that I’m involved with. About all I get the time to do is update, compile, and test! MASM32 has come in handy a couple times now recently (again, I used MASM a lot back in the day). Great for knocking out some quick code where you really need to see how the hardware/software calls are going. Combine it with OllyDbg and you’ve got a great setup for that kind of thing. I also went back to another language from the past, Modula-2. Needed to knock out a couple of quick 64-bit (so MASM32 would’nt work) Windows apps and didn’t have money to spend. After searching around for awhile, I ran across the (recently released as freeware) ADW Modula-2 compiler. Hey, I know (and like) that language! So, that became part of my toolkit as well. Obviously there also domains specific languages which fall into here (and also support above stacks as well). SQL, javascript, etc don’t need their own whole discussion, you know where they fit.

So, that’s it, just a quick rundown on the major toolset divisions I look at when I’m working with a project. What’s yours?


Thoughts on Telecommuting

Having gained some experience with telecommuting over the last few years I thought I’d put a few of my observations out on the web for discussion. In addition to quite a bit of reading about other’s experiences, I’ve gradually transitioned from always being on-site to being mixed on-site/telecommuting at DoX Systems over the past 4+ years. I’ve reached the point of being primarily remote as far as number of times I “go to work”, but my actual hours spent “at work” tend to run about equal on-site vs. remote. Over at Service Spring Corporation, I’ve been almost completely on-site. However, with multiple locations now, we’ve been forced to build some of the telecommuting infrastructure. While not a true telecommuting situation I do get a lot of benefit from being able to go out to someplace other than my office. I can directly observe the work being done while still having full (well, not quite, but getting closer) access to the resources of the office.

Some of the “pros” of telecommuting that I’ve observed are:

– Company cost savings from space, heat, and power usage reductions. Space savings can come through hoteling or shared workspaces, but this is a difficult concept to implement without just re-enacting the tradgedy of the commons. Group work areas are a way to ease into this. If you’ve got the right set of people, it can be made to work. I’m not entirely convinced that full-blown hoteling can ever work though. Making distinctly individual work areas, but not allowing customization just goes against how people function. If the area is designed as a purely group area it’s more natural and doesn’t bring up all the same territorial issues.

– Despite the “home office” costs, there can be a personal cost savings as well. Consider the fact that a simple office building move that I’m involved with now will cut my drive in half and save me 6,000 miles a year (or $3,000 a year at $0.50 a mile). Add in all the extra hours of commuting time that you save and there’s a lot of time/opportunity gains to be had personally as well (6 full DAYS worth of time for me!). Telecommuting 100% of the time would double my savings.

– So far the couple of studies I’ve read claim measurable productivity enhancements. Interesting as most other supposed productivity enhancing plans actually show a decrease for office/knowledge workers (examples: overtime, 4 – 10’s, “Summer hours”). Conventional wisdom for telecommuting increasing productivity is that it’s due to being able to set up the work environment exactly as needed, rather than as corporate policy (and budget) dictates. I suspect it’s mostly due to the ability to self-structure time into blocks. Our tasks are not in the same discrete bock size as piece/part operators. I may need 2 hours solid to code something. During that time, any interruption is a severe setback and at the end I may need a break. Or, it could be a 45 minute block that’s needed. Either way, the random interruption of the office setting not only disturbs the process in motion but it discourages one from even starting longer blocks. Also, being able to walk away when “brainfried” and do something else is a big benefit. You can come back in an hour or two ready to go again instead of sitting there struggling (which just makes things worse) and wasting the rest of the day.

– Attracting new talent becomes easier. While a full-blown telecommuting arrangement is not required, both the hot experienced talent out there and the fresh talent coming out of school expect it. There’s an expectation among the best of the workforce that not just are the hours flexible, but that the location must be as well. If you want to capture and/or retain talent, that’s the path that must be taken. It also opens up the talent pool much wider as you no longer have to recruit locally or try to convince a distant recruit to pack up and move close (often with the company shouldering the burder of the move costs). Furthermore it avoids the possibility of paying for the recruit’s move, only to have them become discontent. If discontent, they may quit costing you all the hiring expenses. If locked into a contract, they’ll just continue working unhappily. Unhappy employees are not typically among the best performers…

– It’s easy to do quick pop-in and fix jobs. Instead of work piling up into large piles that are harder to tackle, all while the customers are kept waiting, it can be handled in small chunks from whereever, whenever. This makes the worker feel better at the same time as providing better service to the customer. The company looks better as well making it a win-win-win.

On the other hand, there are some negatives to the telecommuting arrangement that need to addressed:

– Lack of face time with co-workers can impede collaboration. Sometimes works is just best done face to face. There’s also a risk of being forgotten. Mostly just an issue if you’re the only one that’s telecommuting. If it’s part of the culture and everyone does it, it’s less of a problem.

– Managing by tracking results rather than purely time in seat is a hard problem. Time in seat is not a good metric to begin with for knowledge workers, but at least it’s easily measured at the office. There are applications being put forth to do the same thing remotely, typically by keeping track of open applications or web sites surfed. It certainly will weed out a few, but doesn’t solve the root cause. Ultimately better metrics and decision making processes must be integrated into the business, and that’s both tricky and time consuming.

– Controlling equipment is another challenging problem. There’s always a tug of war between accessibility and security. Even in the office “Bring Your Own Device” is running up against corporate policies. Moving outside the corporate walls also brings up problems of who owns the equipment, who verifies it’s secure, what happens when damage occurs/who carries the insurance, how is access restricted/equipment recovered in the event of a separation of employment that goes bad. How’s the personal/corporate data split handled? Corporate data on home PCs is risky. Separate machines for home/business are inconvenient. Personal data on corporate PCs has problems as well. It may just require a better HR screening process than the standard office environment needs.

Some of the ideas I’ve been working with in regards to handling the challenges of the modern work environment include:

– Still maintain some office hours. This gives people a predictable time and location to find you for when they just really have to see you. This doesn’t mean the hours can’t be flexible. Publish a calendar with blocks of time and locations if you can’t commit to a regular schedule.

– Out of office meetups, in locations you’d normally have/want to go anyways. Meet up places for lunch/work sessions to keep some face time. Keep it local most of the time/small groups of people that live in the same general area. Occasionally go out of the nearby area so as not to lose track of those further away. Mix it in with errands that take you across town anyways.

– Video conferencing instead of phone calls to maintain contact. Video calls are much more personal than audio only. The phone is a very cold, distant device. A cheap webcam on the computer can enable much richer communication. Online whiteboarding/screen sharing is even better, but just adding video is the biggest gain.

Hopefully I’ve given you something to chew on as the world continues to move towards a better way to work for all!

Bad decisions.

I’ve been reflecting on decision making recently.  To be more specific, the chain of events involved in decisions that turn out bad.  While much of failed vs. good decisions appears to be just plain ol’ dumb luck, there appears to be one indicator in particular that has an impact on the chance of a successful decision.

Simply following the decision through to it’s logical conclusion is that factor.  Often performing that exercise leads to results that seem absurd or nonsensical to our puny little brains.  However, that supposedly absurd event is too often exactly what will happen in the end.  Failures in our risk management cause us to disregard results that we don’t find attractive.  Probably a good thing, or we’d never take a chance.  However, don’t let that sway you into automatically disregarding what seems like an absurd outcome.  Take that result into consideration in the final decision making in order to improve decision-making success rate!