mike.mainguy

I read with interest an article about the mentality behind nosql nosql-vs-rdbms-let-the-flames-begin.html . From my perspective, this debate isn't really a debate and I've written about similar things before. If you stop for a moment and think, it seems obvious that giving up a relational model and giving up ACID compliance reduces overhead. It should also be obvious that you are giving up things that many people for many years have thought are really important. To a person selecting an underlying database implementation, part of your decision making process needs to take these things into account. Here's a quick list of things to consider: How important is speed? (how long can we wait for one operation to finish) How important is scaleability? (how many operations must we be able to do at one time) How much money can I spend? (Can I spend a $200,000 on a honking server?) Who is going to support this system? (A bunch of developers, a bunch of dbas, or both?) How big...

I've spent a LOT of time studying user interfaces and it was all well a mystery until I met up with a few folks who where versed in the "science" of cognitive psychology. I put science in quotes because, as a self-appointed armchair mathematician it is only with much resistance that I can admit that any field of psychology is, in fact, a scientific discipline. After a quite a few conversations with folks who are versed in this field, as well as many hours of listening to lectures on introductory psychology (and more to come) from MIT http://ocw.mit.edu/OcwWeb/Brain-and-Cognitive-Sciences/index.htm I now see with blinding clarity the disarray of the state of things in user interface design. Problem number one is that most, if not all, people who design user interfaces have an opinion about "what the user will think" and frankly I've now gotten to the point where that actually IRRITATES me. I think this is largely because the transference of "me" t...

In my new position, I've spent a large amount of time helping morph my development team's process into something that is a little more effective than what existed when I showed up. What we used to do was have a bunch of developers furiously coding on what they thought was important without actually getting feedback from the business. This led us to an interesting situation where we where spending hundreds of hours developing things that nobody really wanted (sound familiar ?) We've since spent quite a bit of time honing our skills and process to make sure we're working on things that the business (folks who pay us at least) think are important. This work has been rewarding, but not very technical in nature. I've finally gotten some time to play around with really technical stuff again and now remember why I got into this business. The fortunate thing I'm finally realizing is how EXTREMELY rare it is to find folks who can be effective at both managing devel...

If so, take this into consideration and let me know if you think you're still really smart.

I read this post and it resonated with me. The Cult of Being Busy . Honestly, I've riffed on similar things in the past, one thing is good meetings gone bad . As a person who has been this harried line out my cube door person who thought they needed to be the center of the known universe, I've evolved. Frankly, from my perspective, if everybody on my team needs to ask me personally what to do for every operation they perform the team will not succeed. Nowadays, I feel the people I choose to work with must have a certainly level of professional competence and I expect them to act appropriately in the absence of specific direction from me. My obligation in this regard is to respect their decisions and give them the freedom to make mistakes and grow as professionals. This also means that if they should really screw up I need a way to help them avoid this problem in the future. What I see all to often is that most folks think that having their day booked with 10-16 hours of po...

Google Testing Blog: Clean Code Talks - Unit Testing

here's a great, but kinda technical definition StandardDefinitionOfUnitTest but, here's a more general example and an attempt to illustrate "why code is so crappy" and some of the difficulties in translating requirements and designs into "high quality" software. Let's say we have a screen to enter credit card information. Let's further suppose that one of the requirements is to "Validate the credit card information". Let's then say that "Validate the credit card information" means specifically: card types The software written to perform this validation will have a number of "code" units that likely would translate into functions. One of these functions would likely be "validate length of card number". Note: right now we're saying that "function"=="code unit" to simplify things. Let's walk through what we might do to validate JUST Visa and Mastercard length. We'll write ...

Right now I hear rumblings that the "crappy" quality of our software is a direct reflection of our developers not taking the time to "properly" read the requirements. I quote those two words for two very important reasons. Number One: ALL software will be crappy... we're in the dark ages of software development. Accept it, if you think you've written perfect software, you probably didn't stick around long enough to have a hundred (thousand/million) customers. I've never met anyone (sane) who actually believes they wrote perfect software. Most of the time software is clunky and stupid 1/2 way through the project. The answer? Make your projects so small that having it turn into clunky and stupid 1/2 way through is no big deal because everybody knows you'll just fix it in the next iteration (i.e. next month). The only exception to this rule is in wonderland where people just proclaim victory even when the facts of failure abound. Number Two:...

This is now the second time in a year or so where someone has personally confronted me (this time not quite directly, but kinda) about something I wrote in my blog. This time it was in response to a post about services . A friend of someone who apparently thinks they know the unnamed developer in the post sent me a personal email telling me to stop lambasting said individual on my blog. Additionally, I got a few comments on my blog from people who apparently used to work in my organization about how dysfunctional we are and it's all because of a single person who's a jerk. First, My post was my perspective and perhaps it was perceived that I was being too hard on a teammate, but I certainly wasn't suggesting that I had no blame. (it takes two people to have an argument) Second, While that post was spawned by a specific situation that happened, my perspective was formed after working with many people and having a similar communication problem. Just so we're clear, a ...

A while back, I was sitting at my desk and a fellow programmer wandered by and chuckled to himself. He turned to me and asked the following question "If I walk up to pay for something at the store and need 69 cents, what are the odds that I will reach in my pocket and pull out exactly 69 cents?". I thought for a second and said "Probably like on in a gadgillion..." Of course, him being an esteemed mathematician he smugly answered "WRONG, it is precisely 1 in 100" After precisely 7 picoseconds I asked a couple of somewhat random questions: #1 How many coins can you fit in your pocket? #2 Is it possible to get 69 cents using just quarters? #3 Do you always empty your pockets as soon as you have more than 100 cents? He shut me down by saying "you're falling victim to the gambler's fallacy ". Let me do a quick explanation. The gambler's fallacy is basically explaining how people will irrationally think the probability of a future even...

Ever get thrust into a position that you aren't prepared for? If you think so, it's probably not true... What I mean is, most folks who are aware of their shortcomings are usually operating within a zone of competence (partly to mostly competent). Folks who "move up" and feel they are completely ready for it are either: #1 Just trying to get a leg up and don't give a damn if they do a good job or not #2 Completely unaware of their incompetence, generally a nuisance, but fairly harmless #3 A huge roadblock stumbling about and generally unknowingly making a mess of everything they touch. If you are #1, you know you are a #1 and probably don't care, so I believe I cannot help you, therefore I won't say anything more. If you are #2, you likely aren't reading my blog because you rarely put effort into thinking about work while AT work, so the odds that you'd ever try to think about work OUTSIDE of work are pretty low. If you are #3, listen carefull...

OK, eclipse is a widely used development tool and is pretty good, but you know.... It has really stoopid dependency problems that are only getting worse as more and more people build upon it. For example GRECLIPSE-498 really horks me up. I realize that the debian/ubuntu packaging system is partly to blame, but a major selling point (to me) of the equinox platform is that OSGI is supposed to make things better. This bug is an example of how this goal is not really being met. If I have to redownload the entire eclipse platform every time I want to use a new plugin, I might as well just statically compile everything into one big ball of mud and be done with it. In fact, it might be an indicator that the goal is not even worth pursuing. If the only way to determine which components I rely on is for the developer of the component to explicitly specify exactly which specific versions of which dependent components are needed, we are doomed to failure. I'm not sure how we make this ...