Warning: file_put_contents(/var/www/domains/blog.updyke.com/docs/wp-content/plugins/wp-slimstat/cache/cache.php) [function.file-put-contents]: failed to open stream: Permission denied in /var/www/domains/blog.updyke.com/docs/wp-content/plugins/wp-slimstat/browscap.php on line 366

Warning: Cannot modify header information - headers already sent by (output started at /var/www/domains/blog.updyke.com/docs/wp-content/plugins/wp-slimstat/browscap.php:366) in /var/www/domains/blog.updyke.com/docs/wp-includes/feed-rss2.php on line 8
updyke.com http://blog.updyke.com Attempting to tell it like it is Fri, 17 Feb 2012 22:53:35 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Poking around in MySql http://blog.updyke.com/2012/02/17/poking-around-in-mysql/ http://blog.updyke.com/2012/02/17/poking-around-in-mysql/#comments Fri, 17 Feb 2012 22:53:35 +0000 dustin http://blog.updyke.com/?p=525 One of the tools that I have come to love is RedGate’s SQL Search. If you’re not using an ORM, or if you need to get down into SQL Server and find columns, procedures or otherwise, it becomes indispensable to quickly get a handle on a largish database.

In my latest project, we made the decision to ]]> One of the tools that I have come to love is RedGate’s SQL Search. If you’re not using an ORM, or if you need to get down into SQL Server and find columns, procedures or otherwise, it becomes indispensable to quickly get a handle on a largish database.

In my latest project, we made the decision to move to MySql, due in large part to SQL Server’s ballooning cost structure. After a few months of working with MySql, I feel qualified to say that in some ways, you get what you pay for. We haven’t found the tools around MySql to be anywhere near the polish of some of the SQL Server tools (the SQL Server installer itself, not included of course).

In order to find things in our database I did some research on rolling my own Sql Search, what follows are some of the things I have found.

If you want to find a column used in a function:

SELECT Name, CAST(body AS CHAR(10000) CHARACTER SET utf8) 
   FROM mysql.proc
   WHERE body LIKE '%Search term%'
      AND db = 'DB Name';
If you wanted to quickly glance at the whole of the procedure, get rid of those pesky line breaks:
SELECT Name, REPLACE(CAST(body AS CHAR(10000) CHARACTER SET utf8),'\r\n',' ')
   FROM mysql.proc
   WHERE body LIKE '%Search term%'
      AND db = 'DB Name';

If we’re looking for a particular column name:

SELECT * 
   FROM INFORMATION_SCHEMA.Columns
   WHERE table_schema = 'DB Name'
      AND column_name = 'Column Name';

There is a very annoying .NET to MySql bug in that if you have anything but NULL or a 36 character string in any field with a column type and size of CHAR(36), MySql throws an exception. If you have someone testing and they put incorrect data in these columns, no one can select until the data is corrected. Want to find all your potential problem columns then?

SELECT Table_Name, Column_Name
   FROM INFORMATION_SCHEMA.COLUMNS 
   WHERE DATA_TYPE = 'CHAR'
      AND CHARACTER_MAXIMUM_LENGTH = 36 
      AND TABLE_SCHEMA = 'DB Name';

I’m getting more comfortable with MySql now that I know where to look for things. If you’re using MySql, I hope this helps.

]]> http://blog.updyke.com/2012/02/17/poking-around-in-mysql/feed/ 0
A Hammer on Soft Objects http://blog.updyke.com/2012/02/04/a-hammer-on-soft-objects/ http://blog.updyke.com/2012/02/04/a-hammer-on-soft-objects/#comments Sat, 04 Feb 2012 23:02:52 +0000 dustin http://blog.updyke.com/?p=502 I’m writing this from a vacation spot where I thought I had spent almost exactly zero time thinking about my day job.

This is good and a thing we should all do far more often.

I started the day with nothing to do and nowhere in particular that I had to be. So my wife and ]]> I’m writing this from a vacation spot where I thought I had spent almost exactly zero time thinking about my day job.

This is good and a thing we should all do far more often.

I started the day with nothing to do and nowhere in particular that I had to be. So my wife and I took a cooking course with Sous Chef Scott and learned a few simple dishes that were just stunning in taste, presentation and simplicity. Scott is a really nice and laid back guy. We asked all kinds of questions and he answered each of them with a story of his experiences.

Then I wondered around and snapped pictures and I realized how much I enjoy taking pictures.

The reason I love photography is pretty simple. While I love creating things, creating things inevitably draws comments and critique, even when you are not asking for any. The pictures I take are for me. I don’t think I could ever be a professional photographer, aside from not having the skills to be one, but also because when you get paid, you are told which pictures to take. For me, that removes the art and love that goes into composing a compelling photograph.

I have taken photographs that really move me. At some level, I hope you enjoy them too, but that has never been the point of why I love one picture over another. I love them because of their meaning to me. You could say that I should have used flash, or that I pushed the color of a picture too far, and that’s fine.

However, at no time would your comment make me feel guilty for not getting it right. Nor would it affect how I feel about that particular shot. I’d keep it mind for the future, because really, that’s all I can do when it comes to a picture that is already taken, no?

Which brings me to software development. I guess I was thinking about it all along.

Since the last I posted, we launched a major system, in some ways a rewrite of an existing system, in other ways something totally new; which made things complex and had overlapping domain terminology and forced us to make difficult decisions. The requirement gathering was painful because things changed a million times, and we often over-engineered parts of the system because we knew features would be coming soon enough that we would need to account for. Why not build some of that plumbing now? We worked hard and at the end, we were very much red-lining as a team.

We were death marching.

Then we launched and things calmed down and changed. We re-gelled. We had a minimal number of issues crop up, all of which were solved within hours of finding them. It was a success, but, like I said, it wasn’t easy and we certainly didn’t do everything “by the book”.

I’m quite sure we will have disappointed several industry pundits by not following their one true way to getting things done. They would swing their one true sledgehammer upon us with impunity.

In software, we are creating, much like a photograph. People would like to think there is a great amount of science or engineering that goes into it, but really, at the heart of any software project is a need associated with people, and those people are the very reason that science and engineering are a small part of what goes into a real-world software startup project. When we start, we don’t know how big the bridge span is and we certainly don’t know if the bridge needs to support horses, cars or tractor trailers, let alone how many at a given time. Over the span of the project, we will figure those things out and there are certainly ways of coming to those knowledge bits earlier rather than later.

Yet the sledgehammer that my favorite soapbox hero is swinging is likely not a big part of our successes in this project. Using x technology didn’t solve people problems. Going to the cloud didn’t either. A relational database, NHibernate, or otherwise didn’t solve it. Tests, pairing, and readable code were certainly good things that we did on this project, but I noticed that the difference these items made were not obvious. We did them where they made sense. We did not do them where we agreed they were not needed.

To be perfectly clear and precise, sledgehammer topics are ones where x declares that you must do y in order to be professional, successful or likewise. You simply must do x 100 percent, 100 percent of the time!

I do actually wish some of these things were true, but the fact is that we do not live in a black and white world, foremost because at the heart of software is people, and people will always be that unknown factor. Often overlooked is the simple fact that software development rarely controls a business singlehandedly, and the business wields software like a tool, as it probably should.

For us, we wound up not having 100% unit test coverage; but we have a lot of integration tests. We didn’t pair on a lot of things, because there was just too much to get done. We’re working on going back through things after the fact and it seems fine so far. The sledgehammer might disagree. It will bite you in the future! You’ll slow down! You’ll start finding bugs too late! It won’t scale! We haven’t found any of these to be true at all. In fact, things are speeding up and the code changes have been easy refactors. We release daily and customer feedback has been good.

As it is, there really are a few things I think are maxims in software development, but they don’t swing as hard as a hammer. They’re subtle, soft and actually pretty simple. They don’t have the weight of a good profound maxim however, and perhaps that’s why people don’t use them as a weapon:

Simple wins out every time
If you  can’t simplify something, ask yourself if you really understand it well enough. Then reduce it again. Make it more simple. 99% of software is the maintenance and change that occurs after the first time you publish it to production. You’ll have 1000 things on your mind the next time you return to it, so keep it simple and do yourself a future favor.

Low-fi first, then rough in
Every time I just start coding, I stop and draw it out. I go through a lot of moleskines, but if you walk away from a conversation and you don’t draw it out, you risk the old, I thought triangle, you thought square conundrum. The Mona Lisa wasn’t painted one square at a time.

Involve the customer
We had so many features we fell in love with. Customers didn’t care or even notice. Some we had to get rid of and simplify in a hurry. The bottom line is in a startup, nobody’s opinion counts unless they are an actual paying customer.

Communicate often, but clearly
For me, morning stand-ups with the team are a must. I have to know the current status and I assume others need to know mine. Be prepared and be on point. One thing I have noticed is that when you can’t explain over IM and you jump to a call, things can become even more confusing, because people talk faster than they write. That’s the point where drawing and simplifying breaks the fog. Do it often.

Trust your gut
When something starts to feel heavy, or not simple, stop and regroup. When a decision starts to make you second guess things, retable the issue and make another decision. Know when you don’t know and let others know this is uncharted territory.

Be honest and learn from mistakes
If you’ve made a mistake, admit it and let everyone know. If you’re going to fail, fail fast and learn from it. Put something into place so that the issue cannot occur again. Ask other people when you don’t know.

In the end, we built something, released and are starting the next iteration. Customers are happy. Internal teams are happy. We are learning as we go about what to build next and letting customers drive that wagon. For me personally, I’m happy that we got over a hump that was our initial launch, and I’m happy to start thinking about future features that will be really interesting to work on.

Most importantly for me, and in the spirit of my epiphany post, I’m not feeling guilty about hammerish topics any longer and I simply will not do so ever again. Certainly there is always more to learn, more to apply, but it isn’t the case that one thing is going to make or break any given day, feature or project.

I think I can describe it best as, while watching Chef Scott show us how to make Spätzle this morning, I remarked how it takes “a feel” to get the technique of pushing the dough correctly, and he said it just takes practice. “When you do it enough, you know when it is right and certainly when it is wrong”.  The conversation completely reminded me of something a good friend used to say to me often,  ”A good chef never needs a cookbook”.

Yes, at some point you just know. You know by doing and participating.

Wielding a hammer doesn’t teach people. Wielding a hammer doesn’t close the gap between not knowing and otherwise.

Teach by doing. Show a good way of doing things. Be like Scott, and show this is why you do this and why you do not do that. I came to learn, please don’t hammer me. I will always try to do the same.

But for now, I have to go, there are some pictures that need taking.

P.S. Thanks to Ron De Las Alas, Eric Kepes and Eric Reis’ Lean Startup for the idea behind this post.

]]> http://blog.updyke.com/2012/02/04/a-hammer-on-soft-objects/feed/ 0
Retrospective 2011: “A sadder and a wiser man” no more. http://blog.updyke.com/2012/01/02/retrospective-2011-a-sadder-and-a-wiser-man-no-more/ http://blog.updyke.com/2012/01/02/retrospective-2011-a-sadder-and-a-wiser-man-no-more/#comments Tue, 03 Jan 2012 02:57:04 +0000 dustin http://blog.updyke.com/?p=440 It is the end of the year, the beginning of the year, or rather, it is that logical break where I hope we at least retrospect on where we are and where we might go in the coming times.

While we cannot control what might lie in front of us, we certainly can steer the ]]> It is the end of the year, the beginning of the year, or rather, it is that logical break where I hope we at least retrospect on where we are and where we might go in the coming times.

While we cannot control what might lie in front of us, we certainly can steer the ship towards exciting things, exciting people, and exciting opportunities.

If we are not steering the ship in these directions, may I invoke the oldest of cliches and remind us all of how very short life can be? This is not just about work by the way, this is about all things. Work is not life, nor is life, work.

In the past year, I certainly read a lot of things, listened to a lot of people and followed a lot of movements.

I do hope that all of these things work for the people who toil away at their focus in such a way that rainbows fly forth from the keyboards and unicorns stampede in the name of their cause.

But all of these things do not work for me all of the time and I’m quite done worrying about if I am following x or y or z any longer. Perhaps the more you know, the more you worry about those things and frankly:

Worrying weighs you down.

Worrying brings you down.

Worrying slows you down.

In software development, I used to think we had a healthy dialog about our tools, our methods, and our culture. Our obsessiveness was taking us to a better place and we were delivering better software, faster and more often.

Lately however, I look at Twitter and think that we sound like an old couple, bickering just to bicker, just to be right, just to forward our own agenda. We talk about craftsmanship, but I know many builders, contractors and carpenters. They just do not bicker in the way that software people do. They build, period.

I can’t see how the bickering is constructive any longer. Could it be just an albatross that keeps one from building something? That bird has tried very hard and to some extent has reigned in that youthful exuberance I once had. That crassness where I felt like I could build anything at any time.

And so, with no sadness, I must say that, Albatross, your services are no longer needed here.

When is the last time you saw a post about “we had x problem and here is how we solved it” where the focus is on the solution?

Instead we get micro-missives about single methods out of context, “written so terribly that they should float in the Doldrums forever”!

I can’t bring myself to read this type of grocery store rag any longer.

People do things and people make mistakes. Sometimes the two intersect.

Smart people learn from, and fix their mistakes. They adapt. They overcome. They improvise. They don’t sit on the sidelines. They don’t heckle. They don’t hesitate.

So, I’ve been busy unsubscribing and reorganizing on the positive.

I saw someone give a warning a few weeks back about x number of negative tweets gets you an unfollow. Great advice. I’m doing this.

If you’re writing crap, then you won’t be able to ship. If you’re writing crap, maybe you’ll ship just a few times. If you’re not writing crap, then you’re shipping and shipping people tell the best stories. Those are positive stories.

I have a lot of things I have been wanting to build, wanting to try. I think this year I will. Whatever the reasons I did not prior, it matters not. I’ll try my best, but I won’t be lashing myself to the whipping post or wringing my heads over a 50 line method. It’ll get refactored just like it always does, or maybe it will just go away because it isn’t needed any longer.

Or, just maybe it will just work and that’s good enough for right now.

I caught up with an old friend yesterday. Over the holiday, he completed a triple ironman in 49:49:40. Straight through. No stopping. Swim. Bike. Run. 49 hours later, he finished.

He wasn’t always training and he didn’t start competing young. I would have said he was never going to do these things, period. He started four years ago and he didn’t do it any way but his own. He’s always done things that way. He put his mind to it, and made things happen. Four years and 49 hours later, he’s in pretty damn elite company. That’s what he wanted to do, and that’s what he did. So very Yoda.

I was truly inspired by it. I want to live up to something like that.

As a very wise man told me once, “Steer Into the Fear”.

And that is the first move, sliding into your own ship and sailing it yourself. I’m not inviting the lizard brain on this ride. I’m in charge of the damned tunes on the deck and this is how it is.

And I will use this song to lead you on.

]]> http://blog.updyke.com/2012/01/02/retrospective-2011-a-sadder-and-a-wiser-man-no-more/feed/ 3
Personally, I’m Thankful for Startup Culture http://blog.updyke.com/2011/12/02/personally-im-thankful-for-startup-culture/ http://blog.updyke.com/2011/12/02/personally-im-thankful-for-startup-culture/#comments Fri, 02 Dec 2011 15:15:11 +0000 dustin http://blog.updyke.com/?p=425 The startup culture as of late has been taking its lumps on Hacker News and other places, and that’s fine. There are a lot of different perspectives, and I’m not here to tell you which one is right. But I will tell you that being in a startup again is the best thing that has happened ]]> The startup culture as of late has been taking its lumps on Hacker News and other places, and that’s fine. There are a lot of different perspectives, and I’m not here to tell you which one is right. But I will tell you that being in a startup again is the best thing that has happened to me for a long time.

This isn’t a post defending my position or any other. For me, it just is. I wanted to recap things I am happy about; this post is more for me than anything else. Life is short and we shouldn’t be settling. This is a list of why I am not:

Startups are dynamic
I never know what the problems of tomorrow might be.

But never once have they been political; they’ve been strictly technical/process related thus far and none have been life-threatening.

Its fun
We put together a Hubot last month just to play around with the idea of a robot that did our bidding, which led to messing around with node.js and a host of other things. I installed a host of things in the past few months: MongoDB (using it), CouchDB (not as much), Redis (want to use it), Memcached and Elasticache (like it, but not sure we need it yet), Simple.Data (fights too much with MySql) and so on.

I probably would not have done so at a larger established corporation. I remember that I gave a primer on CouchDB once at my last job, and the DBAs left the room in disgust. Here, you push and get pushed. You must be faster and better tomorrow than you were today. You cannot survive without staying in the pit and it seems I rather like the all the pushing and shoving.

Its hard
Developing software is hard to begin with; but, at least I can concentrate on those hard bits, and not sit in meetings all day. Most times the things that frustrate me the most are figuring out business processes or customer problems; normally I want to get back to the code. Its about that point where I remind myself that software isn’t always the solution and understanding the problem before writing a line of code is generally great practice.

I realize I’ve seen this problem everywhere I have worked, the nice thing in a startup is that you’re sitting right next to customers at all times and its far easier to speak with people this way and when you’re a small company. A lot of developers seem to hate this step and unfortunately, there are few jobs where you just sit and code and ignore these types of things.

And why would you want to in the first place?

Its annoying
We tried TeamLab and it was okay, then on to GitHub’s issues and they were fine, but they felt very “tasky” and lacked any context. We all felt the same way, so we moved to Pivotal and forced ourselves to write good cards. We probably should have done this prior, so yeah, we were annoyed with ourselves.

But we changed and we did so in a day. All because of two bitchy standups in a row. Something smelled funny and a small group of people crowded around a smell isn’t going to last. I guess Pivotal was like spritzing ourselves with Febreeze.

I’m me
Hey, you know, I’ll dress up when we need to, but around the office, can I please be me?

We yell, we’re honest, and we get a lot of things done in a week. If something I implement sucks, I hear about it.

But you know what? That’s what I want on my team. Brutal honesty, like an office linebacker, but not quite so hulking and scary.

My time
Yes I work more than I had prior, but I no longer have a long commute so I think they equal each other out. Plus I do things I need to do on a personal level without question and regardless of the time. I get the work done in my private and work life and get on with things.

I get treated like an adult again. I actually like so much what I am doing right now, that I rarely think of things as a “job”. I get out more and I go more places. Double win. Which is sort of odd, because I’m without a car for an extended period for the second time in my life. On that point, just try to be greener than me.

Now do I bitch and moan sometimes? Sure. Do I get stressed out? Yep. Do I totally flip out sometimes when things go totally awry? Absolutely.

But I’ve always done that. That’s me. I’m actually going to work hard on stopping that, because it isn’t awesome and it isn’t positive.

So read what you want about startups being a con or a place where people are overworked. Maybe that is the case. Perhaps some places are very much like that. I’m thankful for where I am right now and through the ups and downs that come with a startup, I couldn’t say 2011 was anything less than an up year. I found my home and my place to be awesome.

I’m looking forward to an awesome 2012, and I hope you are too.

]]>
http://blog.updyke.com/2011/12/02/personally-im-thankful-for-startup-culture/feed/ 0
Well REST-ed http://blog.updyke.com/2011/09/24/well-rest-ed/ http://blog.updyke.com/2011/09/24/well-rest-ed/#comments Sat, 24 Sep 2011 14:03:24 +0000 dustin http://blog.updyke.com/?p=402 So Matt and I were talking about routing, REST and resources yesterday. At StirTrek this spring Mike Amundsen gave a talk entitled: Programming the Cloud with HTTP/REST. Three of the things I took away from there were:

Reconsider the links were propagating. What has to do with the resource one is requesting? What is metadata pertinent to the request? Route accordingly. People have ]]>
So Matt and I were talking about routing, REST and resources yesterday. At StirTrek this spring Mike Amundsen gave a talk entitled: Programming the Cloud with HTTP/REST. Three of the things I took away from there were:

  • Reconsider the links were propagating. What has to do with the resource one is requesting? What is metadata pertinent to the request? Route accordingly.
  • People have forgotten that perfectly valid http responses are being treated as something they are not. A 404 represents a valid response for a resource that is not on this server. It isn’t an error. Don’t treat it as one.
  • Go read Fielding’s Architectural Styles and the Design of Network-based Software Architectures. Seriously.

Steve Klabnik has two good recent and relevant articles here and here as well.

Anyway, two points came out of our conversation that I wanted to highlight:

APIs can be painful to write. You want to follow the best practices and do things the right way, but the technical ability of your users is the wildcard you can never know beforehand. Matt’s said that credentials should be in the request header, and I think he is spot-on correct. However, I am not sure that all users will know how to do this and instead will want to see it in a querystring value.

We both agreed that it has nothing to do with the resource and should stay out of the route (url).

The second point was that if you were looking up an address like:

/address/list/1060 West Addison Street/Chicago/IL/60068

and I didn’t have a record for that address, what is the correct response?

If you answered 404, well done. I don’t have that address, it is not here:

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
-rfc2616 w3c

If you answered that this is an address from The Blues Brothers, then you’re on another level entirely.

In an age where people want to cover up “not found” with custom error pages and such, we’ve forgotten that 404 is a perfectly valid response to a request. It isn’t an error, and it shouldn’t be treated as such. I’ve never met one of those 404 pages that did anything for me anyway; a 404 custom error page is an entire waste of bandwidth.

Have a polling application over http? A 404 response gets picked up in the headers far faster than looking for content that says “that’s not here”.

If you’re just looking for something to be there or not, you don’t even need content to tell you what the header already does.

]]>
http://blog.updyke.com/2011/09/24/well-rest-ed/feed/ 0
A Week with WCF http://blog.updyke.com/2011/09/23/a-week-with-wcf/ http://blog.updyke.com/2011/09/23/a-week-with-wcf/#comments Sat, 24 Sep 2011 01:14:14 +0000 dustin http://blog.updyke.com/?p=399 We are at a point where what was our internal API now must live in the wild as some business partners now need access to different levels of our engine. I’ve written those awful web asmx services in C# enough to know that approach wasn’t going to cut it. I wasn’t sure people were even ]]> We are at a point where what was our internal API now must live in the wild as some business partners now need access to different levels of our engine. I’ve written those awful web asmx services in C# enough to know that approach wasn’t going to cut it. I wasn’t sure people were even interested in XML any longer and some even specifically requested simple JSON. Because of my own experience tooling around with PhoneGap, I know I’d probably pick JSON too. In my own experience generic handlers make JSON much easier to dispense, yet they felt a lot like asmx technology at the same time.

SOAP? We’re not even going to discuss that.

Anyway, I briefly considered just plain MVC, but that didn’t seem like it would scale right. I had no data, this was just a first glance, “well, it can’t be that simple”.

I arrived later at WCF REST Services. Seemed easy enough, I downloaded the samples and had it running quickly. I could inject my own authentication and filters through the servicemodel RequestInterceptor, and it was fairly easy to see how I would map my routes to the things I wanted to expose.

But then it wasn’t. When you look at the configuration sections of the web.config, things certainly enter the realm of Java configuration hell. There is a tool SvcConfigEditor.exe that can help you configure your services and their endpoints, but it failed when trying to edit my ApiKey example. “The behavior needs a name”, so I gave it one, except, then the behavior didn’t actually execute. I fixed that, but wound up getting a little tired of the endless possibilities here.

As an aside, why couldn’t “SvcConfigEditor.exe” be named “Service Configuration Editor.exe”?

After hours of fiddling, I had some of my own examples or tests running and was relatively happy with how things would work. Each service has an interface that defines the service’s contract and each service makes it easy to map different actions and their parameters that you might want to expose. JSON was easy to wire up then as well.

Then I decided to try a client against the service. Hmm, No JSONP?  Well it turns out you can do JSONP, but it certainly felt like I was “fiddling”.

This is where I hard stopped; so much fiddling felt overtly enterprisey to me, and the red flags went up in a 21 flag united wave.

I didn’t need my services accessed over anything but http/s, so most of the other things in WCF were starting to feel like extra things I wouldn’t get to use either.

I went back to MVC 3, and started setting up interfaces and classes just like the service model in WCF. Ok, easy enough. With some help from Matt Otto on the routing, I recreated in two or three hours what took me in WCF almost a day and a half to do.

I totally over-engineered. Guilty.

I think the problem with things like WCF is that their true audience is probably very small; enterprise level stuff. Where a true SOA might be in place. Out in the cloud however, http/s rules the day and I can do the same thing with far less overhead in MVC. Its sort of like EnterpriseLibrary and log4net; the fact is, I just need to log, I don’t want to spend countless hours configuring and setting up something so that I can use but 10% of the functionality.

I’m glad to have taken a look at WCF, but ultimately, I don’t think it fits our need at this time. It wasn’t time wasted however, I thought a lot about simple things, like urls and REST. Let’s call this a learning week. I learned, and it was good.

But that is a post for another day.

]]>
http://blog.updyke.com/2011/09/23/a-week-with-wcf/feed/ 0
Under-Engineering is a Beautiful Start to Any Project http://blog.updyke.com/2011/09/22/under-engineering-is-a-beautiful-start-to-any-project/ http://blog.updyke.com/2011/09/22/under-engineering-is-a-beautiful-start-to-any-project/#comments Thu, 22 Sep 2011 22:51:13 +0000 dustin http://blog.updyke.com/?p=388 If you think about a lot of things in life, they’re over-engineered to the point of no return, aren’t they? Cars are a good example of going well past the realm of must-have. Have you ever lifted the hood on a 1974 BMW 2002? I did, and that squashed any thoughts I had of buying ]]> If you think about a lot of things in life, they’re over-engineered to the point of no return, aren’t they? Cars are a good example of going well past the realm of must-have. Have you ever lifted the hood on a 1974 BMW 2002? I did, and that squashed any thoughts I had of buying an older car. Where would I get parts? Where does the electrical system start and stop? Where the hell is everything?

Of course, my dad’s take on it was, “now this kind of car you can fix yourself! There isn’t anything under there we couldn’t make from scratch if we had to!” I was not moved to action; maintenance seemed all too simple and frankly it scared me.

Fast forward to this week; one of the fog lights on my wife’s car died. I couldn’t figure out how to remove the plastic casing to even see the bulb, let alone replace it. Looking in the manual, it clearly states that fog lights must be replaced by the dealer. I went online and the consensus is, let the dealer muck with changing fog lights.

I cannot even attempt to change my own fog lights. A simple car from 40 years ago scares me. I asked for this vicious circle, didn’t I?

In a world where we can’t change our own light bulbs, it is a scary thing to be prodded into simple action; go build something, go do that one thing you’ve always wanted to do. Do something remarkable; be someone remarkable. That is the challenge.

I’ve said many times, if I could start my own new business that made ten dollars, I could start a business that might do anything, yet I still haven’t made that $10.00.

Is it because my first answer is to engineer the hell out of something new?

There is a fundamental difference in using or buying something and evaluating its technical depth compared to building something oneself.

When I go to buy a car, I see things that are must haves, but they do not weigh on me in terms of “how do I build my AWD system and make it work with my existing RWD 2002″? AWD is more complex than RWD, but in an existing car, someone else has that figured out and it doesn’t impact my ability to use the car.

I didn’t build it and I don’t maintain it.

If I choose to use MVC in a recent project, I might be using it so that I don’t have to write my own framework. I just pick it up and start using it. It either suits my needs or it does not, but I don’t maintain it and I didn’t build it from scratch. Much like buying a car, it fills a need.

However, when we do go and build a new product, this same conclusion creeps in the back door. The big difference here is that you can’t go pick something off the shelf and bring your idea to life; you must build it yourself. You can’t pass off the original engineering and maintenance, you must do it yourself , all the while adding to and building onto your original idea that you should be doing anyway.

Ideas are like barnacles in that way, you can’t stop them from growing.

But the one place we do have control is at the start: Do we take on everything at once, or do we start simple and build out?

Starting a new project is hard because there are so many choices and so many competing ideas in today’s connectivity. I love photography, but sites like Flickr and Smugmug already exist. I couldn’t possibly match all the functionality they have, and so I go back to the drawing board looking for another panacea.

Along comes Instagram. They’re version 2.0 now, which brings a host of new features, but its still a very simple idea executed very well. Most people I know absolutely love it; I’m fairly certainly they love it entirely because of its simplicity.

I’m not calling the engineering in their application simple and I mean no offense, but the idea is simple: Take a picture, share a picture.

Maybe I could have started with a idea like this. Why didn’t I think of something so simple?

Test driven development declares that you should write the simplest code you possibly can in order to make a test pass. This heads off a lot of coding overkill and keeps developers focused on writing concise code that does exactly what the test says it should. I prefer to call them “specs” over “tests” in order to prevent confusion, but that’s just me.

The bottom line is that we’d all take slim and precise classes that get the job done over any other kind of code.

This is probably the best technical example I can think of where simple is the end goal of the entire engineering process.

So, for my next idea, I’m starting absurdly simple. I’m not going to try to match anyone feature for feature. In fact, I’m not going to even think of what anyone else is doing. That problem takes care of itself at some point in the future despite best intentions anyway. I’m just going to take an idea and think of something, anything mind-bogglingly simple, and think of where I might go, what I might do..

If I bought the 1974 2002, then I could change my own foglights. That might lead to installing a new alternator, which might lead to replacing the front wheel bearings. Soon afterwards, pistons might be rolling around on the garage floor.

But I have to start somewhere; better to start with light bulbs than engine rebuilding, no?

I like music, maybe I will start there. What software could I write that does something with a one song playlist?

]]>
http://blog.updyke.com/2011/09/22/under-engineering-is-a-beautiful-start-to-any-project/feed/ 1
Weird is the One Thing You’ve Got Going for You http://blog.updyke.com/2011/09/21/weird-is-the-one-thing-youve-got-going-for-you/ http://blog.updyke.com/2011/09/21/weird-is-the-one-thing-youve-got-going-for-you/#comments Thu, 22 Sep 2011 01:05:42 +0000 dustin http://blog.updyke.com/?p=357 I saw this morning that Seth Godin’s next book is titled:

We’re All Weird

Weird is new and weird is why this world is a great place to be.

Godin has always embraced different ways of doing things, challenging the status quo, and going his own way. He’s the ringmaster in the creative tent, ]]> I saw this morning that Seth Godin’s next book is titled:

We’re All Weird

Weird is new and weird is why this world is a great place to be.

Godin has always embraced different ways of doing things, challenging the status quo, and going his own way. He’s the ringmaster in the creative tent, paving the way for people to do things their own way, whenever they choose to do so.

The thing that strikes me about him and his writing is that he is so very unassuming, so very simple. So how is it that something so simple always feels like a jolt when you read it for the first few times?

Because simple is so very hard.

What he is challenging people to do is very hard for them to accept. Simply go out and do. Seth would say not to listen to the lizard brain that says “but you’re weird, that idea is weird, its all so weird”.

It is a scary thing to be prodded into simple action; go build something, go do that one thing you’ve always wanted to do. Do something remarkable; be someone remarkable. That is a massive challenge.

But you could just go do it. You could be weird.

“All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.” ~ Arthur Schopenhauer

I remember how weird it seemed when the first iPhone came out with its singular button. How weird the touchscreen typing seemed to be. I guess it is still really weird to have to pay so much for SMS messages, that is still not terribly self-evident to me.

Today the button just is, and we really don’t use it much. The keyboard? Nobody is pining to go back to a separate pull out keyboard are they? Well, okay, BlackBerry users are, but they are a dwindling bunch, no?

Facebook just changed its UI today. Everyone is screaming how weird the new layout is, the noise in there is deafening: “Stop the change”, “Bring back the old”, “we hate this”, ad nauseam.

The new layout just is. Within a month, the change will be all but forgotten and accepted for what it is, the Facebook layout.

When VHS faded into DVDs, streaming movies were beyond our comprehension. When streaming started to happen in music and moves, it seemed weird to not have physical copies of your own. I paid for it, I need a “physical” copy!

In short order, we’ll see that our misuse of the term “physical” isn’t what people have been thinking. Streaming won’t be weird any longer, it will just be.

Weird is simply the starting point of something else. It is difficult to stay weird forever. Weird is a transitional state. Things very often go from weird straight to accepted.

People meet, its weird, and they move into another phase. One blurts out an honest  idea and a relationship moves from weird to brilliant in the sharing of a single pint.

Weird is what we all bring to the table. Weird is new and hopefully, we all have new things in spades. New ideas, new experiences, new friendships.

If you’re afraid of being weird, you’re just afraid of new, afraid of change, afraid of the inevitable.

New is going to happen; you may as well be a part of it. Be weird and be you, because most problems, most businesses, and most people need more weird in a bad way.

Either way, you’d still be weird anyway.

]]> http://blog.updyke.com/2011/09/21/weird-is-the-one-thing-youve-got-going-for-you/feed/ 0
Netflix’s Guilty Ignorance and a Social Wildfire http://blog.updyke.com/2011/09/21/netflixs-guilty-ignorance-and-a-social-wildfire/ http://blog.updyke.com/2011/09/21/netflixs-guilty-ignorance-and-a-social-wildfire/#comments Wed, 21 Sep 2011 11:32:26 +0000 dustin http://blog.updyke.com/?p=362 I admit, I didn’t expect to have thoughts on the Netflix implosion, but I guess I do, and so it goes.

Netflix’s lack of understanding their customer in the information age is simply unacceptable.

The outcome of poorly executed company strategy and every knee-jerk decision at the corporate level is a potential social wildfire. How much ]]> I admit, I didn’t expect to have thoughts on the Netflix implosion, but I guess I do, and so it goes.

Netflix’s lack of understanding their customer in the information age is simply unacceptable.

The outcome of poorly executed company strategy and every knee-jerk decision at the corporate level is a potential social wildfire. How much damage and how long these fires last is uncertain, and that should be well enough reason to avoid them at all costs. Certainly their costs can be high: Reputations are tarnished, PR and the hype machine must spin into overdrive, which in itself always carries some amount of risk, and the company becomes hugely unfocused as the events play out.

These fires used to be in the control of the media. With blogs, Twitter and Facebook, this is no longer the case. Distributed complaints are much harder to reach, and therefore, much harder to quiet.

Netflix is a company that, prior to this fiasco, I routinely used as an example for how we should build our own business. Forgoing the monolithic apps of the past, Netflix has done an exemplary job of building a cloud based architecture that just works. Even through massive Amazon outages, Netflix was available and showed us how to correctly build a redundant system capable of withstanding the previously unthinkable.

Building chaos monkey and an infrastructure guaranteeing such a high amount of uptime takes a massive planning effort. Developers, ops, and management had to come together and put a plan in place that had never been undertaken before. All of this was a herculean effort on the part of the company.

So the question is, for all that planning, how did what started as a pricing change shake the company to its bones?

Were these recent decisions thought out as well as their platform was? Did they do the simple, “what if this? What if that?” scenarios I find myself thinking through late at night when I can’t sleep?

The simple answer is that they could not have.

As a response to outrage over pricing changes, they again made a quick and unclear decision to split the company into two in an attempt to further manage the situation.

This just added fuel to the fire.

I think we’ve seen evidence of what happens when customers ultimately don’t understand, don’t like or don’t believe in a company’s decision or direction. Facebook, AirBnB and now Netflix have all been caught in consumer wrath and all managed to make a situation worse by trying to manage it in a half-cocked manner.

Remember changes to Facebook’s privacy settings about a year ago? The follow up to the initial outrage from Facebook was a series of screens that further clouded what consumers had control over. After that they worked to smooth out the screens and ultimately give consumers a level of control that they were looking for.

Remember the AirBnB customer who had her apartment ransacked, identity stolen and the company’s mismanagement of the firestorm that ensued?

Seems to me that it boils down to these companies all trying to strong arm the customer and making decisions not based on any kind of customer input or data. The masses will no longer be strong armed, for at the very least, they’ll complain about it on Twitter.

Not making decisions based on real data, particularly for these companies, is simply idiotic, because they have accumulated vast amounts of consumer data just by the very nature of their business. Netflix customers visit the web site often enough they could have easily piloted changes to smaller groups of people. They could have just asked a few key questions.

Instead, they made a decision ignorant of this customer data and told their customers what they should want. It did not work. When that did not work, they did the same thing a second time. Until you know what might put the fire out, you probably should refrain from putting your company or your people in harm’s way a second time.

A simple query would have told them the number of customers using both DVD and streaming services. Another simple query would have told them which way people went when pricing split the two services.

If there were a million people still wanting the DVD service, then I would argue that is a million people too many to alienate.

Contrast all of this with Amazon or Etsy, who both make very small incremental changes to their websites often. They run these changes with subsets of users in order to perform real world tests of what their responses are going to be. The review the output of those tests and adjust accordingly.

They make decisions based on real customer input. The data drives their decisions.

When you know what your customers want, expect and will tolerate, you will not find yourself having the unpleasant task of trying to manage an unpredictable social wildfire.

]]> http://blog.updyke.com/2011/09/21/netflixs-guilty-ignorance-and-a-social-wildfire/feed/ 0
Non-technical success http://blog.updyke.com/2011/09/20/non-technical-success/ http://blog.updyke.com/2011/09/20/non-technical-success/#comments Tue, 20 Sep 2011 12:10:43 +0000 dustin http://blog.updyke.com/?p=322 Living a life immersed in technology, sometimes I forget the massive power that we wield with just a few keystrokes or mouse clicks.

My grandmother was born in 1926. She and her siblings were children of a pre-technical era.

I spent some time over the past few days cleaning up some photos of her from the ]]> Living a life immersed in technology, sometimes I forget the massive power that we wield with just a few keystrokes or mouse clicks.

My grandmother was born in 1926. She and her siblings were children of a pre-technical era.

I spent some time over the past few days cleaning up some photos of her from the 30s and 40s. My wife had some of them reprinted and the rest I made into a simple iDVD movie/slideshow, of which I made copies for several family members.

We gifted my mother with one of these framed prints this weekend. I can emphatically say that the power of a simple photo from the past made new again cannot be understated. My mum was absolutely stunned that we had printed a photo that meant so much to her and that she thought was beyond being printed again. The DVD was also very well received and people were genuinely happy to have access to so many family pictures that now so many can enjoy.

This post is not about what I did or how I did it. I just used the computer to do something decidedly low tech: Print a picture and make a slideshow on a disc.

My point is that not everyone loves the computer for the reasons we do. Not everyone reads Hacker News everyday. Not everyone cares that PhotoShop can make text look like it is on fire. Not everyone understands why Git is great. Not everyone knows what a unit test is for and why it is important.

This is okay; actually, this is a great thing that the geeks of today are missing.

My father can fix or build anything. Well, almost anything, as long as it isn’t a computer. His bug reports drive me crazy because all I get is “the printer is broken” or “Skype doesn’t work” or “there is a fluke in Amazon that I found” and I have to figure out what might be the problem from there. On the other hand, he provides me with some unique gems like “it would be great if there were software for x” or “this is too difficult, here is what I want” or “this makes no sense to me; here is all I wanted to do”.

You’d never run out of software to write if you hang around decidedly non-technical people and listen to what they are saying.

What does that “non-technical” term mean anyway? Actually, we rely on “non-technical” people every day; to build our homes, fix our cars and the like. It is these people who don’t live online everyday that are talking about the genuine state of computers today. I don’t think we can see it objectively anymore. We are too close.

It is likely that we have adapted our lives around the computer, instead of making them work optimally for us.

There are probably very simple things we could do, perhaps in the way of explaining software and services in a better manner that would open new worlds for people who use computers not as much as we would like to think they do.

It starts with not dismissing those people as “not technical”.

There are lots of articles on how any given technology works, on how a certain business is successful and how agile software practices are revolutionary.

I don’t see a lot of articles on how the computer simply makes life better for people.

I wish that I did.

]]> http://blog.updyke.com/2011/09/20/non-technical-success/feed/ 0