Tag: opinion

Categories
business personal

10 Joys Of Small Business Ownership

Don’t fret about those woes! For on a daily basis…

  1. You are building something greater than the sum of its parts.
  2. You set the mission, vision and values.
  3. You define the right people, right roles, and right rules.
  4. You will push constantly to explore and learn to think outside your comfort zone.
  5. You will often fall, but consistently stand up stronger… usually.
  6. You will grow leaps and bounds professionally and personally.
  7. You will come to understand the wisdom of those you admire, and fear.
  8. You are pursuing your dreams and will pity those that lack the courage to pursue theirs.
  9. You have no limit to your possible successes.
  10. You are the driver of your destiny.

I’d also like to emphasise that none of these items are directly focusued on the immense financial wealth of which we all hope. Over time wealth may or may not come, but the common factor amongst all great entrepreneurs is the primary importance of personal satisfaction regardless of monetary riches. At times–and during all stages of business–progress can require a certain amount of financial masochism and sacrifice, yes, but always should you be proud of what you’ve done, where you’re headed, and excited for the treasures of the next day.

Categories
computer

The Truth About Integrating Rails In The Enterprise

Ruby on Rails is a great RAD framework. We use it all the time. But one place Rails loses its magic–while not the fault of the framework itself–is with external integrations to legacy systems.

First of all, soap4r sucks. Everyone I’ve seen try to pick it up has gotten frustrated and angry at how awkward it is to write a SOAP client in Ruby compared to Java and .Net tools, which can do the same thing in a matter of minutes. Since RoR IDEs aren’t exactly 1337 yet, we need to put some serious love here as a community to prevent larger companies with heavy SOA leanings from running away screaming.

For some reason, many people seem to think that pouring t3h Rails int3rn3ts into an infrastructure will suddenly trim 75%+ off all development and maintenance costs, complete with rounded corners and shrink-wrapped buttons. Wrong. Many of the development tasks will take significantly shorter times to develop under timeframe expectations relative to Java and .Net, yes, but you can’t avoid costs associated with migrating legacy data and integrating with retarded external systems such as your ghetto-ass SOAP services. Nor should you avoid design activities such as usability analysis or proper testing practices. 

So if you have a web project that lives in complete isolation and does not have any legacy issues with which to deal, OpenRain can bust out that web project in a heartbeat. But if you have unresolved data management and integration issues, there is no acts_as_silver_bullet plugin which can save you the burden of having to actually think about and address those problems. Rails isn’t the cold bucket of water for your data nightmares.

Categories
computer

Hiring For IT: What We’re Doing Wrong & How To Fix It

HR departments for many technology firms tend to be a bit backwards in the way they evaluate potential hires. Early in the process, an HR member or technical recruiter will typically contribute to the never ending stream of listings posted to the popular online job sites, and funnel the subsequent flood of applicants through a filter before passing on candidates to the geeks. The key issue is that HR cannot realistically be expected to hold all the technical knowledge necessary to appropriately evaluate and filter applicants based on technical criteria. Many resumes are thus evaluated solely off keywords or ridiculous automated online exams that supposedly quantify a candidates abilities based off asinine declarative factoids.

My personal hiring strategy, while admittedly skewed towards finding only top tier entrepreneurial people, follows these steps..

  1. Go to the core of The Right Persons culture. Forget about the “Java” checkbox on Dice.com. Figure out what The Right Person does online, and go there directly. Post a Java job to the local JUG mailing list, or a Ruby job to the Ruby talk group, for example. Only people genuinely into these topics sign up for mailing lists and forums, so by going straight to the cultural center of the ideal candidates interests you’ve already filtered out the dingbats who would apply just for the sake of applying. The Right Person is probably already employeed and thus would not be checking monster.com anyway. Allow HR to apply their own filters after you’ve identified the right culture.
  2. Evaluate their communication skills via email and phone. When was the last time you read an uber-competent technologist who ended every sentence with three exclamation points and a smiley face!!! 🙂 Yeah.. me neither. The subtleties of written language reveal how in touch one is with technical culture. They might have extensive experience with 16 different databases on their resume, but if they can’t explain — in layman’s terms — what a database driver does, I can’t see him/her being able to produce well-documented results or be terribly useful in business meetings. Ar-tic-u-la-tion of one’s thoughts in both written and spoken word is critical to effectiveness.
  3. Talk about technology in general. I do not expect you to know the internals of the JVM to be qualified for a Java developer position. I do expect you to keep current on general technology trends and always have your ears open. I expect you to constantly learn and get your hands dirty, and I expect you’ve done some of it on your own time.
  4. Ask the right questions. “What type of Exception does Socket.close() throw?” would be the wrong question. Phrase your technical inquires such that they are open ended, recognize that He/She Is Not Google, and allow the respondent to give an intelligent response even if they do not know the answer. Example: “How would you describe the lifecycle of a network connection?” The question is specific enough such that a knowledgeable person can immediately give a thorough answer, but not overly so such that it is a miniscule factoid you’d see on Jeopardy. Also ask questions which are subjective or provide incomplete information, such as, “Which Java OR/M technology would you use in a new web application?“. You’re not looking for a “correct” response, but to gauge how’ll they’ll react when prompted with incomplete, unclear or clearly stupid business requests. Just like the real world. Arrogance and stubbornness can often show through with a definitive answer to such questions, whereas a more pragmatic person might say “It depends.” followed by a diatribe on the pros and cons of various options, none of which a singularly “correct”.
  5. Invest the time. Many large companies outsource recruitment because they see it as a secondary distraction to the organizations primary tasks. But the thing is… putting the right people in the right roles is as core to your business as it gets. And for the prices charged by technical recruiters, the $20K+ per head can easily be spent on competent geek personnel dedicated to networking in the correct communities for purposes of recruitment.

But don’t fret: there are companies trying to change the system. For the time being, however, keep this mind next time you hear an interview going on down the hall…

Organization and role-specific cultural requirements come first; HR policy requirements come second.

Categories
personal

Everyone Should Grow Up Poor

There are only two relatives I’ve ever known to whom I’ve felt a strong biological connection. One of them died last month. This is a tribute to her…

I spent the majority of my early childhood growing up with my mother in a single-room add-on attached to the side of my grandmothers house in a Northern suburb of Chicago.

My mother never went to college and worked very hard to keep us financially safe doing jobs such as data entry. She is a very hard worker that gains personal satisfaction from a job well done and was always gainfully employed, so we were never poor in the hungry, homeless or other romantic sense, but firmly lower class, yes. My mom still loves to tell the story of how I didn’t understand you could purchase food without a coupon clipped from the Sunday paper. She didn’t have a lot of free personal time due to being a single parent, but made it work. I don’t think I would handle that lifestyle well, and have a tremendous respect for single parents trying to make ends meet while “being there” for the kid(s). I was even fortunate enough to get a hand-me-down obsoleted Macintosh computer from my mother’s coworker on which I typed school papers from elementary school until high school.

The land and house I grew up in had been established by my grandparents some years after World War II. My grandma grew up on a farm and filled the house walls with rural-feeling nick-nacks and small-town artifacts. The surrounding neighborhood became caught in urban sprawl and began to transform into luxurious mansions settled comfortably on 1-acre lots.

My father is a South Korean immigrant who came to America for a better life, and eventually found his place in California. The balls it takes to pack a suitcase and move to a foreign country with a pocket full of dreams continues to astound me. I recall listening to him confidently lay out his plans to run his own successful businesses as so many other Asian immigrants did in Los Angeles. Looking back on the first 18 years of my life, I now realize…

Having less in an environment of opportunity can be empowering.

When you have less, you feel like you must improve yourself to be noticed amongst peers. No one can fix a situation with a magic wand should you fail, so you must dedicate yourself to tasks because success will not otherwise come. And if you succeed, you’re not stuck with a convoluted sense of entitlement to a world full of subordinate peons. You know exactly how hard it is to make it in life because you’ve seen the sacrifices and tears from your family and friends. You chose your fate, and made it come true.

I enjoy the niceties in life just as much as the next guy (who doesn’t?), but I feel good that I don’t feel entitled to them. I know that if I get a nice dinner or fun new toy, I earned it, and I’m going to be more proud and protective of it than if you just handed it to me. It’s not just another disposable object; it’s mine because I consciously caused a chain of meaningful events resulting in a reward. Push the button, get a treat.

So here’s the deal. If you win the next Powerball jackpot, you get to keep a few million to secure your home, family and reasonable lifestyle, and have some fun while you’re at it. Go for it. Take a vacation on the International Space Station or something. I’d do the same. But you don’t get to blow $5 million in Vegas or $50 million on a toy.

You hire a financial management team and get to work doing something meaningful with your fortune (and your life) by sheltering homeless children, curing cancer, something. Make the world a better place. And if you’re investing wisely, you’ll feed off the inherent greed of the system and use the profits to further your own philanthropy. Keep the compassion, dreams and simple contentment of being poor, and use the power of being rich to change the world.

The fated rich have not such empathy for the masses.

Do not strive to be rich. Do not strive to possess. Do not strive to control. Do not seek admiration of the world. Do not seek approval of authority. Do not strive to be popular. Do not be a pessimist. Do not dwell on the past.

Strive to be wise. Strive to be kind. Strive to be selfless. Strive to be loving. Strive to be more. Strive to do more. Strive to use less. Strive to be an example. Strive to leave the world a better place than you found it.

Strive to redefine humanity.

Categories
computer

The Three Types of Start-Ups

At OpenRain Elite Web Software we’ve seen all the popular combinations of startup business models when evaluating new projects. Here is a breakdown of the three most common startup models based on financial structure, the pros and cons of each, and recommendations on which one to choose for your new venture.

 

1) The Pop-Start

The pop-start–short for “popular startup”–is the stereotypical venture capital (VC) or Angel backed venture wherein an initial product prototype is created with a small angel fund, pitched to investors once (barely) operational, and subsequently funded for $1M+ in a second, third etc. round to fund growth to a profitable status. As each round is collected, additional personnel are generally hired immediately to kick off additional production development in a (hopefully correct) high-velocity direction.

Pros

  • Should you raise enough in your initial rounds and find the right people, you’ll be able to keep the company operational in the early growth stages without incessant worry on keeping positive cash flow, which, depending on the idea, may not be possible.
  • Fast growth once the big investment dollars roll in.
  • A minimum of personal risk since only the initial angel round will likely come from close ties. 

Cons

  • Tons of investor pitches and marketing/sales-speak on vaporware which will drive technical people insane.
  • Legal issues from the get-go. Expect difficult negotiations with second round investors and costly legal fees.
  • You’ll have to put up cash for airfare, lodging, marketing materials, legal fees etc. up front for possibly dozens of remote meetings. The costs add up fast.
  • Large amounts of constant pressure from investors.

This is for you if…

  • Your idea requires a substantial capital investment to get off the ground, such as $100K in federal licensing costs or $500K in manufacturing equipment for a first line of production product. You legitimately need this funding to get off the ground, and the amount is too large to put up yourself.
  • Your exit strategy is getting bought out by Google for $100B.
  • You can afford the risk of working on this full time, with little (or no) compensation up front and no gaurantees on a second round of funding.

 

2) The Weekend Warrior

The proliferation of online services for company creation has allowed many dreamers to create legitimate legal business shells in free time for hundreds of dollars. The weekend warrior start-ups are those who believe in the idea, but cannot financially afford to quit day jobs.

Pros

  • Low risk. If the company fails, you still have your day job.
  • Low cost. You still have the income from your day job, so eating small operational costs should be easy. If you’re supporting a large family on a single income, this may be your best option.

Cons

  • Making progress is painfully slow since it’s an “in my spare time” project.
  • People will not take your business as seriously since you are not committing your livelihood to it.
  • The logistics of getting things done off-hours can be challenging, such as finding the time for calls during business hours without interfering with your day job.  

This is for you if…

  • You can only commit yourself to working nights and weekends.
  • You cannot accept large financial risk.
  • You do not require large capital investments to reach financially sustainable operation.
  • You can accept the fact that progress and growth will be slow.

 

3) The Self Serve

Self Serve businesses are full-time owner operated organizations which grow based on their own performance, rather than external investment. They are self-funded, full-time ventures which put the responsibility of success squarely on the owner(s) since there is often no formal governing board. OpenRain’s web development business started this way, and continues to be entirely self funded.

Pros

  • No pressure from investors.
  • Full-time personal investment gives you time to put operations in order.
  • Will be taken seriously by potential clients/customers.

Cons

  • Self-funded. This can be mitigated by limiting personal credit exposure, but there’s no getting around the fact that initial operating costs will need to come out-of-pocket, and losses may personally bite you regardless of the precautions you take.
  • Personal pressure to constantly generate income since your personal income will be determined by the performance of the company.

This is for you if…

  • External funding is not appropriate or necessary for your idea.
  • You (and you business partners) are comfortable operating the entirety of a business amongst yourselves, our are able to invest in quality people to fill in the holes as soon as possible. Technical work, finances, marketing, sales, human resources, operations and 8000 other miscellaneous tasks will crop up needing someone’s attention. And that someone is you.
Categories
computer

What If Ruby Had Final Variables Like Java Or Erlang?

ruby

After a long confusing Ruby debate today at OpenRain on the merits of functional, Erlang-esque write-once-read-many variables, I’m going to step onto the podium and just say it… Ruby should get “final” or “const” variables in a similar semantic style to Java, except at runtime. Rather than ramble on for 12 paragraphs explaining exactly how this might work, read this fictitious Ruby code snippet instead. (Optional: Also check out the chapter on “final” in Hardcore Java.)

Final variables like this are really just an inline TDD mechanism.

Allowing local stack data to be constant provides no functional enhancements to the software, but alleviates the need for certain types of tests by using the compiler and/or runtime to assert certain memory is immutable. The “friend_best” method variant in the code snippet would obviously break most existing Ruby programs, but ups the bar for defensive programming by preventing many common bugs out-of-the-box while still providing support for traditional Ruby variables. At the very least we should have something like “friend_better”. Adding this information to the parse tree will also make it easier for IDEs to provide features more easily implemented for static languages.

TDD/BDD is in–no qualms about it–but we can make our code safer, cleaner and more concise by applying some of the lessons learned by our statically-typed language cousins over the last few decades.

Categories
Uncategorized

Identifying Senior Software Engineers: Six Critical Differences

For HR and legal purposes, most development companies classify Software Engineers into ranks from I to IV (or V). The higher the rank, the higher the responsibilities, expectations, independence and pay grade. To cut it as an interviewer and manager, you’ll need to classify people accurately with a minimum amount of direct personal exposure: a non-ideal but practical requirement of most hiring processes.

While we don’t regularly use titles at OpenRain, we nevertheless have to distinguish senior talent. The core issue is, “How do you objectively identify ‘senior’ engineering qualities?” Today we’ll focus on several key factors always present in quality engineers, independant of language and platform.

Instinct

He/She has developed extraordinary technical relevance filtering to the point of being able to scroll through a never-before-seen 500 line file in a language they don’t know, and tell you..

  • how complicated the code is.
  • where potential bugs are.

Even with no formal knowledge of code smells or design patterns, a senior developer can sense ugly code and architecture from a mile away even if they don’t yet know exactly why.

Foresight

Long-term implications are always on the mind of the Senior Software Engineer. They’ve been through the end-to-end development process (from requirements gathering to product maintenance and end-of-life) numerous times, know what issues are going to arise and will point out a suitable solution long before the symptoms start to appear. (This quality thus becomes most apparent after delivery when work is bombarded with never-before-seen use cases.) The truly elite developer is often hard to identify because they’re solving the important issues before anyone else notices the problem. (Ben is a primary example of this extraordinary perceptiveness.)

Results Focus

Knowledge without application leads to arrogance without insight. Senior developers are always focused on results which stand the test of time and can easily see through posers who fluff their way through status meetings.

Communication

New developers seldom understand the required differences of communication between different types of stakeholders. Newbies tend to treat all stakeholders as authoritative figures, and are quick to lose direction when exposed to people with differing incentives.  The criticality of non-verbal developer communication is also apparent to the senior engineer.  For example, a green engineer may see issue tracking as micro-management, automated testing as an ideological obsession, and project planning as administrative overhead, but these are all monumentally important aspects required to keep all developers and stakeholders in a real-time communications loop, since many do not directly interact. A senior engineer will see these concepts as empowering and often get grouchy when not present, because not having clear priorities and documentation introduces roadblocks to results.

Time & Priority Management

A senior engineer can more-or-less tell you what their schedule looks like a week out, even if it’s not written down, and won’t be hesitant to express any issues with workload ahead of time.

Estimation

New software engineers seem to invariably produce time estimates magnitudes off from reasonable numbers. The issue largely appears to be one of Foresight since accurate estimates are oft best produced by benchmarking current requirements against past similar project experiences: a task more easily accomplished with experience. This issue is an arguing point against the “Customer is Always Available” aspect of eXtreme Programming since a green developer is generally more likely to over-commit to a workload than a senior.

Categories
computer

Five Major Apple Design Irritants

Apple,

My software development firm–OpenRain in Arizona–spends buckets of money on your products. Stuff works pretty well in general, but you really need to address these issues. Really.

  1. PowerBook, MacBook and MacBook Pro power supply cables invariably rip. Not only that, but it’s always at the same freaking places. The MackBook/Pro power supplies are better than the PowerBook ones, but still don’t last more than a couple years of real-world use. The issue is at the endpoints of the laptop end of the cable that get bent constantly from travel and being wrapped sharply when the electric outlet is on the wrong side of the laptop. I really love the small and agile design, but the cables need to last at least 4 years without tearing.
  2. Laptops still run hot. Phoenix summer get hotter than 110 degrees Fahrenheit, and I have gotten physically burned by the MacBook Pros when wearing shorts. Product such as the iLap are amusing, but should not be necessary. Getting physically hurt by a computer is a problem.
  3. Keyboard are not ergonomic. The latest iteration of post-modern laptop-style bluetooth keyboards are great to look at, but absolutely horrid on the wrists. No one at the office really likes them in practice, and we’ve had to revert to the Microsoft Natural series of keyboards when have been around f-o-r-e-v-a-r but Apple hasn’t responded to. I’m 100% confident you could build a swanky, highly usable bluetooth keyboard that puts the Naturals to shame.
  4. iPhone copy/paste support. It’ll be an awesome design accomplishment when we no longer need this, but you haven’t gotten there yet, sorry, and everyone else agrees. Add copy/paste support (if only in key areas) to iPhone.
  5. iPhone needs to support dvorak. Yeah yeah…. I know I’m in the minority on this and am sneaking it in, but I spend a lot of money with you guys, and having to use QWERTY just for the iPhone is driving me insane. Add the freaking layout please.

 

 

Categories
personal

Dear TSA, Check Out The 4th Amendment. Thanks.

Just a little food for thought for your next airplane ride. The 4th amendment of the U.S. constitution reads..

The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.

Sounds reasonable to me. And now, the little note from the TSA left in my checked bag, neatly tucked between my clean, folded boxer shorts..

The full text follows below the line..

Transportation
Security
Administration 

NOTICE OF
BAGGAGE INSPECTION 

To protect you and your fellow passengers, the Transportation Security Administration (TSA) is required by law* to inspect all checked baggage. As part of the process, some bags are opened and physically inspected. Your bag was among those selected for physical inspection.

During the inspection, your bag and its contents may have been searched for prohibited items. At the completion of the inspection, the contents were returned to your bag.

If the TSA security officer was unable to open your bag for inspection because it was locked, the officer may have been forced to break the locks on your bag. TSA sincerely regrets having to do this, however TSA is not liable for damage to your locks resulting from this necessary security precaution.

For packing tips and suggestions on how to secure your baggage during your next trip, please visit:

http://www.tsa.gov

We appreciate your understanding and cooperation. If you have questions, comments, or concerns, please feel free to contact the TSA Contact Center:

Phone:866.289.9673 (toll free)
Email:TSA-ContactCenter@dhs.gov
*Section 110(b) of the Aviation and Transportation Security Act of 2001,
49 U.S.C. 44901(c)-(e)
Rev. 8-1-2004
Smart Security Saves Time
Categories
computer

Sufficiency In Software Testing

 

When I was finishing up my B.S. I took a class in embedded software testing. The big assignment was to write the software that controls a single elevator, test the software to our satisfaction and deliver the whole shebang at the end of the semester. The critical lesson I learned from the course was not that the elevator software was difficult to write, but that there are an infinite number of odd and unfortunate events that could happen to any component involved, at any time, and there is no way to declare with 100% confidence that you have accounted for all possible defects.

So most software is not about perfection, but sufficiency. Everyones wants ultra-high quality, defect free wares, but at some point you must put down the keyboard and declare the product “sufficient” for release. Key problems: “How do you know when you’ve done enough testing?” And just as important, “When is the right time to test?”

This topic has been a open talking point at OpenRain. Marc is a strong proponent of many TDD/BDD principles and goes knife-throwing-freak-show when stuff isn’t well covered. (Ed. note: possible slight exaggeration… maybe.) I am also highly concerned with sufficient tests, but prefer a incremental approach and am wary to invest too much effort in automated tests up front for several key reasons.

  1. While development is underway, you incur unnecessary overhead to maintain tests developed before design stabilization. This overhead is inevitable during long-term maintenance, but the last thing I want to do on the project I started yesterday is refactor all my tests because I dropped a single column from the “users” table.
  2. When inexperienced developers write tests too early, they oft end up testing the dummy data and underlying framework, not your design. It is not our job as application-level developers to write test cases for all underlying dependencies, but since that’s all you have at the beginning of a project, it’s easy to waste time here.
  3. The benefits of writing tests first to flush out design details is diminished in dynamic languages. In Java, writing a quick block of pseudo-code to use your interface is a great way to explore your design from an “external” perspective. Once you’ve achieved design clarity, you can easily use your compiler errors to create correct interfaces. Dynamic languages such as Ruby, however, do not offer this compile-time help, lowering the benefit of the technique.  
  4. There’s no freaking way we’re checking in code that doesn’t compile. Sorry, but if I’m writing a Java unit test, there’s no way I’m putting up with 800 compiler errors (and no autocomplete) over the next day while I generate all my stubs. I don’t care if TDD says otherwise; it’s a stupid practice for statically typed languages.

Granted, if any of our systems crash, we probably aren’t going to irreparably harm anything except for my phone that goes flying across the room for ringing at 5AM, but we still have the issue of “sufficiency”. For OpenRain‘s Rails-based applications, I’ve been using the following philosophies on a personal level.

  • Models tests should be implemented first and as soon as possible. Validation logic and other constraints should be verified up front, as key bugs here will likely effect other code. Add sample data as necessary.
  • Only functional/integration tests for core use cases should be done early. Adding too many upfront tests to the yet-to-stabilize design tends to add maintenance liability before it’s able to pay itself off.
  • Tests for non-core features should be tested shortly after a brief “breathing” period, wherein others can comment on the design/code before you’re fully committed to it. Don’t waste your time with a massive test suite until people stop telling you it sucks.
  • Avoid complex methods of testing. Multi-threaded and singleton-based designs have inherent testing complexities, and should be designed out if possible.
  • Aim for 100% coverage in dynamic languages. Otherwise you won’t catch retarded bugs like syntax errors.
  • Have all known, likely and anticipated issues resulting in a significantly negative state covered by an automated case. This is, perhaps, the crux of my “sufficiency” perspective. You must have some mental benchmark that determines when you are “done”. This does not imply that all issues are resolved, only that they are tracked and, hopefully, all the significant ones are fixed.

I’d love to hear your thoughts on practical testing philosophy. Please let me know what you think!