mike.mainguy

After years of keeping it a secret, I'm finally going to let folks in on how to select software development tools. The great thing about my process is it applies to programming languages, frameworks, design patterns, and many other development aspects (even 'non software development' things). Here's the process: Does your current tool support your business goals? (things like: speed to market, cost, uptime, available programmers of the appropriate caliber) If yes, why are you reading this? you already have a tool, get to work. Can you modify your existing tool (keeping in mind the modification needs to take into account for business costs of modifying the tool) so that #1 applies? If yes, get to work modifying it. 90% of the time, I've found you don't need this step, but if you do...look for tools that more closely align with #1, try them, and go through the process again. There you have it! Five simple steps to the ultimate software development too...

This morning I saw a Facebook post from a fairly liberal friend about how he watched something on Fox News and couldn't believe people thought this stuff was real. It's interesting to me, because of course it's "real", but it's only telling the parts that their audience want to hear. So to that end, I thought I'd share some tips on how to detect bias and separate "opinion" from "fact". I'm not a journalist, but this skill is very helpful in "real" life too. All people can have a variety of opinions, some deeply held, some changing all the time, but some people confuse opinion with fact and it is a major reason reason for conflict. Opinions are judgements (hopefully) based on facts, facts are verifiable For a little more detail, here's a pretty good assessment I won't go into detail, but a key thing to consider is "how can I disprove this?". If it is possible to disprove something, then it...

I'm not really a political guy, in my lifetime, I've voted for: Bush, Clinton, Nader, Mccain, and Obama, so it should be clear I'm all over the board and have no political affiliation (If you're keeping score, that's 2 Republicans, 2 Democrats, and a Green Party candidate). In previous elections I was largely indifferent to the primaries and really only started researching a month or so before the election. The cycle, while I still ignored the primaries (largely), I did a little bit of research as the VERY broad republican field and the interesting wild card (Bernie Sanders) on the Democratic ticket was unavoidable (thanks twitter and Facebook! :). As we near election day, I thought I'd share my observations as a person who "doesn't have a horse in the race". What I mean by this is the following: I don't care about political ideologies... Political Parties such as: Republican, Democrat, Green, Constitution, Natural Law, Pirate (yeah, it...

Setting aside the obviously sexist tone, one thing I've noticed (aside from the dearth of female programmers) is that, at least on my team, the female programmers seem MUCH better at asking good questions. While I realize the sample size is too small to be even remotely scientific, I have a couple of observations that seem to hold true. Female programmers seem to do "just enough" research before asking questions and can frame the question in a way that makes reaching the crux of the question very easy. Too often with male programmers (especially junior ones), I get questions that amount to "I'm stuck and I don't know what to do" ... with no background or research ... so I end up playing a game of "did you google the error message?" "what is it you're actually trying to do in the big picture?" or "what have you already looked at?". Worse yet, with many male programmers, they will have spent a month rewri...

I won't bore you with details, but I will point to an interesting article on a rise in microagressions and the concept of a "Victim Culture". To recap quickly there are three primary types of cultures discussed #1 Honor Culture - were you generally have a personal code of honor and use force to correct even the slightest of offenses #2 Dignity Culture - were you ignore insignificant (that is, legally allowed) slights and rely on dialogue and third parties to dispute offenses according to a unified, documented written code, and #3 Victim Culture - were you use the perception of victimization to resolve disputes. In Honor cultures the strong are rewarded for being strong or oppressive and there is nothing to check their power. This leads to adaptations in behavior that favor the idea that "the strongest make the rules". Moreover, the rules tend to be arbitrary and (inherently) serve those who are already in positions of power (or in the case of revolution ...

Having purchased a raspberry pi 3 a few weeks ago, I was quite confused by almost every reference for install mentioning "plug in HDMI monitor and USB keyboard" as a step. While I've found references on how to do a headless install, it seems that many of the instructions come from a background of "you've already installed and run the graphical installer". As a person coming from an arduino/linux server background, I really don't need X11 for my use case and just want a powerful micro controller that I can setup via ssh (well, USB would be better, I still don't understand why you can't do this using the USB connection as a tty...but that's a different discussion). What follows are the steps I used...NOTE if you use the wrong disk number you will destroy potentially important information on your machine, use at your own risk and only do this if you understand what this means otherwise you will likely have an unusable machine or at a minimu...

The software industry expends a lot of energy making sure software is tested. From unit testing, to system and performance testing, to manual "poke it with a stick testing", almost no software team "doesn't do it" or fails to see the need. Ironically though, many places don't routinely test their IT operations and business processes. This is ironic because if those things are broken or brittle, it generally has a MUCH larger negative impact on a company than buggy software. To clarify, I've worked with many companies that have a "backups" and "disaster recovery plans", but they never TEST to see if either of this can actually lead to a recovery in the timeframe expected. A well known (for me at least) scenario in the IT field (related to operations) is this: "Yes we do backups" Server fails, all data is gone Build new server (this works) Restore data that was previously backed up Realize backups actually were w...

"Let it crash" is a watchword in the Erlang world that has a pretty specific meaning in that context, but can be seriously misapplied if taken out of context. In the erlang world, a "crash" is the termination of an actor in it's specific context. In a well designed actor system, the actors have very specific jobs and if they cannot complete that job they are free to fail immediately. This is a bit of a problem for folks working in the JVM world as crash can be overloaded to mean things that change the semantics of a transactional system. Real world(ish) example: Suppose you have a distributed system that accepts a message, writes it to a data store, then hands a new message off to three other components. Suppose further that the transactional semantics of the system are such that the job isn't "done" until all four operations have completed and are either #1 permanently successful, or #2 permanently failed. The important detail ...

Problems in the “Internet of Things” Having worked with connected vehicles for a number of years now, there are some things that it seems newcomers always “get wrong”. Having worked through the “plain ‘ol Internet” (POI) boom, I see parallels between the mistakes made during that period and similar mistakes in the current ongoing boom. I’ll outline the biggest few: Failing to recognize mobility In the POI, people used a client/server paradigm to design applications for the web. Additionally, the protocol generally chosen was one designed for document management, not application connectivity and it too almost a decade before general purpose alternatives arose that were better suited for the types of interactions desired. Moreover the general interactive design tended to try and replicate a desktop experience instead of design for the new platform. The problem here is that the device “might not be where you think it is” or it may have even “fallen off the network”. Without go...

In a discussion yesterday about how to know if our code was thoroughly tested, one of my tech leads mentioned "Unit testing without a code coverage tool is like painting a wall while blindfolded". I think it's a very apt metaphor, and something that developers should take to heart. In most modern programming languages, there are tools to both automate unit level tests as well as determine how much of your code was actually executed as part of a test run. To run unit tests without validating what has and hasn't been covered is unprofessional. Imagine if you hired someone to paint your house and the first step is to blindfold themselves...what is your confidence that they will do a good job? What amazes me is that I've heard a number of developers repeat this phrase "My professor told me that 100% code coverage is practically impossible"...which seems to lead them to the inevitable conclusion that "so therefore I won't write ANY tests"...

There has been a recent spike (well relatively ancient in software terms...) in the term Software Craftsmanship . This is the notion that developing software bears more resemblance to a craft or art than to a scientific pursuit. This is a very accurate and a good explanation for why guilds and other artisanal concepts creep into software development circles. I've noticed interesting contrasting correlations in folks who "grew up" developing software to solve problems versus people who learned computer science or computer engineering at a university. While the latter generally have a more sound grounding in the theoretical underpinning of "how computers work", the former have a better grasp at "how software delivers value". Put another way, computer scientists and computer engineers seem to have a focus on the nuts and bolts of how computers work instead of how to get them to do new and valuable things. This is not a BAD thing, but losing sight...

I heard an interesting statement (just minutes ago) that really struck a chord with me. agreed, we need to have a balance between proceess and flexibility which both resonated with me, but also sent a shiver up (and down) my spine. A common thread I see is that folks who like "process" tend to be "inflexible" and people who espouse "flexibility" do so at the expense of "good process". I disagree violently and think this is a false dichotomy. At the end of the day, "a crappy process" or "an ad hoc process" both still a "process", and having either of those processes is no more or less flexible than having a vigorous and dynamic process that supports what you're business objectives. The problem as I see it is that "process" has gotten a bad rap because many egghead know-nothing consultants have sold horribly convoluted and untenable processes to folks and when said customers see their effectivenes...

Having worked a number of years with connected devices, I thought I'd like to briefly share some observations and pitfalls that folks just arriving to the field should heed. The network isn't always there Many folks arriving on the scene of connected devices come from a background where their applications ran in the datacenter and connectivity was a user's problem. That is, if someone tries to use your site, can't, then tries google and it doesn't work...they assume the problem is on THIER end. While this isn't universal, it's much more likely than someone who tries to turn off the lights in their house or start their car and it doesn't work. While wireless providers do a very good job of connecting when devices are reachable, there are so many variables that impact coverage for a wireless device, it is almost impossible in most cases for a user to make a determination what is casing their "thing" to not work. This is especially aggrava...