Nov 24, 2010 Posted by John MacIntyre

Response to Seth Godin’s – Where do ideas come from?

Seth Godin is wrong I just read Seth Godin’s blog post Where do ideas come from? And in my opinion he completely missed it. Sorry, I think Seth is awesome as do many others, but on this one, I don’t think he really answered the question; where do ideas come from?  Instead, in my opinion, what he wrote was more a list of favourable conditions While I’m no Seth Godin, I’m going to share my understanding of ideas and their source[1]. I hope I don’t need to explain why a post about ideas and creativity is on a programming blog. Ideas come from questions Ideas are answers to those questions. Although it may appear that ideas come out of nowhere while driving to work or zoning out in the shower, they are really answering previously asked questions burning in your subconscious.  There are many conditions which help answers come more easily, but they never come if you don’t have the question in the first place. Questions need to be installed into your subconscious A fleeting question doesn’t quite make it into your subconscious to be answered later.  The question needs to be important enough to be prioritized by your mind. Installations depth comes from emotion The importance of the question is largely based on the intensity of the emotion driving the question.  That’s why many innovations come during massive change and crisis.  Fear and greed inspire many ideas. New information is assimilated to answer these questions New questions are never installed for questions you already have the information needed to answer it.  So you need more information to answer the question and will need time to assimilate new information which is filtered against your question. This information can be from; feedback from action, random thoughts in the shower, synergy, social media, blogs, news, conversations, books, radio, lectures, etc…  And yes, Seth even television[2] Fear constrains ideas Fear eliminates ideas.  Whether criticism of a bad idea, or constraint, or even a well-meaning, ‘helpful’ person who’s experienced proves it cannot be done. When people fear criticism, ideas are never put forth which may inspire better ideas.  All ideas must be valued for an innovative environment. Forcing ideas constrains you to existing information You’ll hear many people say that you sit down, brainstorm, make your decisions quickly and take immediate action, which is great, when you have all the information you need.  But unless you have all the information you need, forcing... read more

Oct 4, 2010 Posted by John MacIntyre

My reaction to being named as a Canadian programmer worth following on Twitter

Yesterday John Bristowe published a list of Developers in Canada You Should Follow on Twitter. I was humbled and honoured to make the list. … actually, I was a little more excited than that, here’s a dramatization …. Watch this video on YouTube … Thanks John … I’ve been dying to use this video in a blog post.... read more

Oct 3, 2010 Posted by John MacIntyre

The UI programmers (not so) secret weapon

An Example: Suppose you had software which matches buyers and sellers, and new users are created via a ‘new user’ wizard[1].  Let’s say the wizard has 4 pages for Basic User Info, Review, Processing, and Completion Status Report.  And there are 5 buttons; Cancel, Previous, Next, Run, and Finish. Cancel is displayed from the Basic User Info, Review, and Processing pages. Previous is displayed from the Review page. Next is displayed from the Basic User Info page. Run is displayed from the Review page. Finish is displayed from the Completion Status Report page. This isn’t difficult to manage the display from the events[2] right? Well … in reality, it doesn’t take much of a change for your simple display functionality to become … The Problem Manipulating application display during events quickly turns into a complex, bug riddled, difficult to maintain, mess. It may not seem like that big of a deal when you have only a few controls and a very simple (or no) workflow.  Actually, you may argue, managing visual display in the events may even seem like the most efficient strategy.  After all, you will never display, disable, or otherwise needlessly manipulate a control, but as your application grows more complex, this approach can leave you tearing your hair out[3].  This is especially true when you have multiple execution paths leading to the same event handlers with different state. What if you received a change request for the above requirements, where additional info is required for buyers or sellers, resulting in a new wizard page for each, and in addition to that, business sellers require a page to gather Tax Information? Your complexity has started to grow, resulting in buyers have a workflow of Basic User Info -> Buyer Info -> Review -> Processing -> Completion Status Report Individual sellers have a workflow of Basic User Info -> Individual Seller Info -> Review -> Processing -> Completion Status Report And commercial sellers have a workflow of Basic User Info -> Commercial Seller Info -> Tax Info -> Review -> Processing -> Completion Status Report Notice how these changes lead to different execution paths all arriving at the Review page.  The question then, is; where does the back button on the Review page send the user?  The back button requires logic to know which wizard page to display. It’s not difficult to imagine the need for logic to be added in more than one place[4], which can result... read more

Sep 19, 2010 Posted by John MacIntyre

My week (09/18/2010)

Blog Posts Earlier this week I posted What is too simple and small to refactor? about a  follow up to my first Clean Code experience where I took a very small function, and refactored it.  In the end I was truly questioning; how small is too small to refactor?  This post received quite a bit of a response, including a response from Uncle Bob Martin and several refactors from Cliff Mees, Neal Blomfield (his response), Cory Fowler,  Ben Alabaster begin_of_the_skype_highlighting     end_of_the_skype_highlighting, and even Jon Skeet. My Twitter Worth Mentioning(?) “..I’d explain why, but I have to, like, go put on lipstick.”-@aalear responding to a comment “females are too busy being beautiful” #gogirl 8:25 PM Sep 15th My recent blog posts have generated a lot of feedback among my friends & colleagues. I’m glad. It’s a great conversation. 12:09 AM Sep 15th I’m going to create a restaurant review site & call it StickyTables.com 12:51 PM Sep 13th “Clean Code is a design philosophy more than a naming convention.” – me #justQuotedMyself #dealWithIt 😉 12:36 PM Sep 13th If somebody says my code sucks & they’ll redo it, I’d be hurt. But for my design, I’m relieved. #msPaintSucks 😉 10:56 AM Sep 13th Just saw a really cool job title on LinkedIn “Experienced Code Poet” 11:04 PM Sep 12th When I hear “the cloud” I know I no longer understand what the other person is talking about. #widelyMisusedTerm 9:58 PM Sep 12th Friday; I love you, but you come way too fast. #in 7:12 AM Sep 17th Even when they score a major coup to attract & add value to users, the announcement is littered with comments like “Who uses @MySpace? ” 11:16 AM Sep 16th Got to say; one of the biggest challenges I have blogging is coming up /w relevant examples. 8:17 AM Sep 16th #FF @unclebobmartin not for his Clean Code msg, which is awesome, but for addressing your questions & concerns. #wayToGo about 19 hours ago A programmer started to cuss Cause getting 2 sleep was a fuss As he lay there in bed Looping round in his head Was while(!asleep()) sheep++; 9:13 PM Sep 8th (this wasn’t mine, it was quoted from a StackOverflow question) In my opinion ‘no written requirements’ is the biggest kiss of death a project can have. #stackexchange http://bit.ly/d3rho2 5:42 PM Sep 8th I don’t hate technical buzzwords, only the ones non-tech people have hijacked. 4:17 PM Sep 16th Wisdom from Twitter... read more

Sep 14, 2010 Posted by John MacIntyre

What is too simple and small to refactor? (Clean Code Experience No. 2)

Shortly after reading Clean Code, I refactored the data access layer from a project I was working on, and was amazed by how much the code improved. It really was night and day. My first clean code refactoring experience was an obvious improvement.

I was still on that clean code high, when a little function entered my life that I was compelled to refactor. This one left me questioning the limits of what I should refactor and if my refactor even qualified as clean.

I’d like to share that second experience with you in this post.

read more

Sep 10, 2010 Posted by John MacIntyre

Procedure Like Object Oriented Programming

In a previous post What’s wrong with the Nouns/Adjective/Verb object oriented design strategy, I talked about how verbs should be implemented in their own separate class instead of as a method strapped onto an entity class. In my opinion, it’s an appropriate way to work with processes and pass those processes around, while keeping code flexible, testable, and highly maintainable. But it has led to comments on Twitter and a link to one of Steve Yegge’s post Execution in the Kingdom of Nouns. Basically, Steve said that turning verbs into nouns was a bad idea (at least that’s what I think he was getting at, there were a lot of metaphors in there :-). It’s easy to see Yegge’s point of view, if you just leave it at that. After all turning your single line of code accessing those actions 1 commentData.Insert(cn);commentData.Insert(cn); into multiple lines of calling code, when you move the logic into its own class, 1 2 3 4 using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { insCmd.Execute(commentData); }using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { insCmd.Execute(commentData); } definitely sucks. So why not add a static method to the process class so you can access it with a single, procedural like, call? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class CommentInsertCommand : IDisposable { ....   public static void Execute(CommentData commentData, int userId, SqlConnection cn) { ValidateCommentParameter(commentData); using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { commentData.CommentId = insCmd.Execute(commentData, userId); } }   protected static void ValidateCommentParameter(CommentData commentData) {...} }public class CommentInsertCommand : IDisposable { .... public static void Execute(CommentData commentData, int userId, SqlConnection cn) { ValidateCommentParameter(commentData); using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { commentData.CommentId = insCmd.Execute(commentData, userId); } } protected static void ValidateCommentParameter(CommentData commentData) {...} } This way your call is reduced to 1 CommentInsertCommand.Execute(data, cn);CommentInsertCommand.Execute(data, cn); I think this has merit and is a clean way to manage your classes. It brings your object oriented code back to a more procedural level. One problem I haven’t quite figured out yet is the naming. To be honest, I’m a little uneasy about it. I should probably name it ‘Insert’, but that’s redundant with the class name and I’m not crazy about naming it ‘Execute’ or ‘Run’ either. I chose ‘Execute’ in this example so all XXXXCommand classes would be consistent across the application, and the name is consistent with the SqlCommand naming which is important since this class kind of emulates... read more

Aug 24, 2010 Posted by John MacIntyre

My Clean Code Experience No. 1 (with before and after code examples)

Public Code Review Robert C. Martin was kind enough to review the code in this post at on his new blog Clean Coder. Be sure to read his review when you finish reading this post. Introduction After expressing an interest in reading Robert C Martin‘s books, one of my Twitter followers was kind enough to give me a copy of Uncle Bob’s book Clean Code as a gift*. This post is about my first refactoring experience after reading it and the code resulting from my first Clean Code refactor. Sample code The code used in this post is based on the data access layer (DAL) used in a side project I’m currently working on. Specifically, my sample project is based on a refactor on the DAL classes for comment data. The CommentData class and surrounding code was simplified for the example, in order to focus on the DAL’s refactoring, rather than the comment functionality. Of course; the comment class could be anything. Download the my clean code refactor sample project (VS2008) Please notice: 1. The database can be generated from the script in the SQL folder 2. This code will probably make the most sense if you step through it 3. This blog post is about 1,700 words, so if you aren’t into reading, you will still get the jist of what I’m saying just from examining the source code. What Clean Code isn’t about Before starting, I want to point out that Clean Code is not about formatting style. While we all have our curly brace positioning preferences, it really is irrelevant. Clean Code strikes at a much deeper level, and although your ‘style’ will be affected tremendously, you won’t find much about formatting style. My original code My original comment DAL class is in the folder called Dirty.Dal, and contains one file called CommentDal.cs containing the CommentDal class. This class is very typical of how I wrote code before reading this book**. The original CommentDal class is 295 lines of code all together and has a handful of well named methods. Now, 295 lines of code is hardly awful, it doesn’t seem very complex relatively speaking, and really, we’ve all seen (and coded) worse. Although the class interface does seem pretty simple, the simplicity of its class diagram hides its code complexity. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25... read more

Aug 1, 2010 Posted by John MacIntyre

What’s wrong with the noun/adjective/verb object oriented design strategy

The programming course I took way back in 1993 was basically a 1 year intro to C. And like any good student, as I learned the language, I also started learning about code reuse and experienced a delightful satisfaction every time I realized 2 different functions had similar code which could be moved into a new function. Eventually, I noticed a pattern, in that I would write a bit of functionality until it worked, then I would refactor it into a more elegant solution with as little repeated code as possible. My code evolved quite nicely. Then I learned C++, object oriented programming, and was introduced to the holy grail of object oriented design advice, which went something like this: Take your requirements and circle all the nouns, those are your classes. Then underline all the adjectives, those are your properties. Then highlight all your verbs, those are your methods This Noun / Adjective / Verb design strategy seemed like the most ingenious piece of programming wisdom ever spoken … but it’s led us down a misguided path. It’s the verb that’s misunderstood. The verb should be another class, not a method. It should be a process class. As a programming concept, a process is just as much a ‘thing’ as any real world object. The verb should be a class, which accepts the noun as an input to be processed. But there’s also another problem; Up until this little shortcut was articulated, code was structured based on the implemented code, with similar functionality refactored into its own reusable units, but once noun/adjective/verb idea became widespread, code was suddenly structured according to domain. For example, the domain focus was really evident in the way we structured our ‘is-a’ relationships, with inheritance being based more on the real world domain, than the implementation code. Inheritance should be based on most efficient code reuse, not the domain, because as anybody who has heard the square is not a rectangle* example can attest, sometimes the domain ‘is-a’ relationship just doesn’t work. * With regards to the square is not a rectangle example, please be aware the solution outlined does not resolve the problem, as described in Uncle Bobs comment. The 1996(?) magazine article, The Liskov Substitution Principle is available, which contains the example as originally described. I didn’t post this url, since it’s not focused exclusively on the square / rectangle issue. Copyright © John MacIntyre 2010, All rights... read more