Raymond Lewallen

• Benefits of Root Cause Analysis

  Root cause analysis (RCA) is a methodology used to solve problems at their root, rather than just fixing the obvious.  RCA is often equated to a kaizen improvement process, and rightly so, as it often digs into possible organizational change, rather than localized optimizations.  The benefits of RCA are that it uncovers relationships between causes and symptoms of problems, works to solve issues at the root itself and provides tangible evidence of cause and effect and solutions. If a seamstress makes a shirt, and one sleeve it longer than the other, the easy fix is to fire the seamstress and hire a new one.  However, the next seamstress makes the exact same shirt, with the exact same flaws.  This introduces cycles and waste and lost revenue and increased overhead because RCA was not performed.  Had an RCA kaizen event been triggered, we could have started with the “Why”s.  Why was the sleeve too long?  Because the seamstress sewed it that way.  Why did she sew it that way?  Because that’s what the plans said to do.  Why did they plans call for one sleeve longer than the other?  Because that’s what the measurements were.  Why were the measurements off?  Because the person who recorded the measurements measure from the top of the shoulder for one sleeve and the bottom of the shoulder on the other sleeve.  Why did he measure from two different points of reference?  Because he was not adequately trained.  Why was he not adequately trained?  Because we assumed he didn’t lie on his resume and his training was adequate.  The point is, we’ve identified the need to either train or hire a new person to take measurements, not a new seamstress. If you count the “why”s above, you see we’ve dug 5 deep.  The 5 whys is a concept credited to Taiichi Ohno (the father of the Toyota production system) and is used to dig to the root of problems.  However, it has its flaws.  The flaws aren’t actually with the process itself, but the act of the process performed by an individual or team.  If at any point the wrong question is asked, it may send you off on a tangent that isn’t going to lead to the root cause, thus provoking you to take action on the wrong cause.  Keep in mind, that you don’t have to stop at the 5th why, but rather the concept is to dig as far as is necessary to identify the root cause of the observable effects. Above, we’ve taken the process from “fingerpointing” to the seamstress, to a learning process to identify the root cause of the problem.  By getting to the root cause of the initially identified problem, we may have also solved many other issues, such as inseams on pants being of different lengths, again, because of the measurements, thus preventing pants with legs of varying lengths. The quality metrics of a clothing factory do not allow for shipment of these unusable clothes, and if you have those types of quality metrics, you need to have improvement processes in place to quickly and thoroughly identify the roots of problems without spinning your tires firing and hiring seamstresses. Software is much more difficult however because tangible artifacts are not always present.  Its often that we find bugs and hack together fixes, rather than performing RCA to understand the full chain of events and relationships so that the actual root cause is identified, fixed and possibly fixes other bugs that could happen in the future.  In that sense, RCA is both reactive and pro-active. RCA is a process that introduces organizational improvements in many situations, lasting improvements and most importantly, a learning process to follow for thorough understandings of relationships, causes and effect and solutions.  By practicing RCA, you eliminate taking action on possible causes, and delay a response to the last responsible moment when the actual root cause of an effect is identified. Posted Dec 20 2008, 04:49 AM by Raymond Lewallen with 9 comment(s) Filed under: Agile, Alt.Net, Lean

• The purpose of value stream maps are not the value stream maps

  Value stream mapping is an activity that stems from lean methodologies used to capture and report on processes from beginning to end.  Once the value map stream is complete, you have a visual representation of the process and its activities such as inventory pulls, kanban signals, “milk runs”, buffers, load leveling and value processes themselves. Once a VSM is complete, is now becomes a communication artifact, and to a certain degree, obsolete.  Once you have the VSM, you now have the information you went in search of, and the VSM is nothing more than a representation of knowledge. The identification of steps that create value and steps that create waste are the ultimate goals of production of the VSM.  The purpose of the map isn’t the map, but the learning processes.  Its the granular evaluation of specific processes within a process that produces the knowledge required to trigger kaizen events and make process improvements. Once the knowledge is acquired and understood and a kaizen event triggered, future state maps can be produced to show where process improvements can be made – increasing (where applicable) and streamlining value adding processes, and removing wasteful activities.  The future state map shows a more desirable VSM which is used to produce an action plan that can be introduced into the process and improvements made. I was in the process of putting together VSM templates for Excel, and a colleague of mine made a good point when I asked him for input.  Paper is portable.  Pencil can be erased.  The longer you sit and evaluate a process, the more you find yourself erasing and making changes. That being noted, and taking into consideration what I said above, I’m not sure I see value in digital VSMs at all.  They are short lived (when acted upon) artifacts the don’t require the effort it takes to screw with a tool outside of standard pencil and paper. Posted Dec 05 2008, 10:42 AM by Raymond Lewallen with 4 comment(s) Filed under: Agile, Alt.Net, Lean

• Identifing Waste, the Lean Way

  As mentioned in a previous blog post, waste elimination is usually the most obvious and least resistant way to improve value and flow in a product.  So I’m just going to jump right into some of the waste factors that are usually easy to identify, evaluate, modify and sustain their solutions in software product development.  Not going to cover all forms of waste, just the most common ones. Bugs and Defects. A bug, in simplist terms, is any behavior of the system that do not meet the expectations of the customer.  Defects have a bit broader scope of who’s definitions cross into other forms of identifiable waste.  A defect may not be a symptom of the product itself, but rather of the team, or communication patters, or materials transportation, or processing and production.  Missing a deadline is a defect, but it is a defect of a larger entity than the product itself, same as missing information (most commonly found in requirements gathering, prioritization, feedback loops).  Bugs cause rework.  Rework is waste.  Retest is waste.  Every single bug and defect, no matter how large or small, has an impact on the overal production cost of a product, due to having to revisit ideas and code that have been addressed in a previous cycle. Movement of Artifacts and Materials in Excess (Transportation) Unnecessary movements are wasteful activities, and by unnecessary, I mean movements that do not add value.  Routing is probably the largest culprit of excess transportation.  Routing of materials is usually something that has room to be streamlined and improved and should be looked at promptly.  Signature requirements, too many eyes involved, processes out of sync or sequence, lengthy lead times, report approvals, data replication techniques, poor configuration management, lengthy feedback loops; all of these are usually causing too many movements to be involved in order to achieve a goal and end up increase the cost of production.  One thing not so obvious?  Office layout.  Yes, the layout of the facility in which teams work in very often causes excess movement of resources.  Think about that one. Wait Waiting overlaps into excess movement a bit, but still has its own caveats.  Feedback loops.  This is where most software teams have room to improve in waiting.  In manufacturing, its usually materials and inventory shortages that cause excess waiting.  When you wait, you waste.  That’s obvious and simple.  Waiting pops up in so, so many ways in software development.  Document generation and reviews, bugs and defects, resource shortage (not enough staff), somebody on vacation when collective code ownership is not practiced, no continuous integration, no unit tests, wrong kanban levels, manual and lengthy deployment scenarios, poor workflow… I could go on and on.  Usually in software, like mentioned in the beginning of this paragraph, its feedback loops.  And more common, is feedback from your own product, not the customer themselves.  Feedback in the forms of unit tests, integration tests, build servers, metrics reports, code reviews, a customer on the team etc are critical to the elimination of waste generated by waiting. Backlogs (Excess inventory) In manufacturing, this would be identified as excess inventory.  Scrum is an obvious process to identify “inventory excess” in the form of a complete backlog.  In lean, any backlog item that cannot be identified as a customer need based on actual, current demand, is excess and should be gotten rid of.  If its important, it will resurface later.  Managing those excess backlog items is a wateful activity and may cause issues that lead to less than ideal planning and processing.  Removing excess backlog items that are not pulled based on current demand may surface issues that need to be addressed, such as hidden processes and schedulings that are causing waste. Over-processing Over-processing is most commonly found in the form of writing a piece of code that does not pertain directly to the needs of the customer.  Beahvior driven design is the way I use to elimate this wasteful activity.  By practicing behavior driven design, I know that each and every line of code can be traced back to a customer requirement.  Code that is written because you think you might need it later, system reconfigurations, unnecessary refactorings, writing code is a very elaborate way when something simple will suffice; these are all wasteful activites and are not adding value to the product. Over-production This ties a bit into over-processing, but production is a result of processing, so when you have over-production, you’ve already over-processed.  Building modules that are not required and completing items when they are not part of the current demand of the customer are forms of over-production.  Even though the customer has not requested a feature, if you have built it, now it become excess inventory in the product that has to be maintained (carrying costs).  Not only that, its much more likely to have to be reworked when and if the customer does make a request for that feature, if it doesn’t become obsolete alltogether. Posted Sep 04 2008, 10:00 AM by Raymond Lewallen with 11 comment(s) Filed under: Lean

• An entry into lean

  I, like many others, have been head deep into lean methodologies such as kaizen, kanban, 5S, value streams and lean in general.  As I continue to learn and practice these things, I’m going to start publishing, much like Laribee is with his focus on Kanban, in order to gain feedback and ideas.  I’m going to cover things in a bit more general matter than just approaching one methodology, but hope to hit on them all. Today I just want to give a primer into lean so those of you who haven’t done much reading into it have a foundation from which we will build. When you hear lean, its difficult not to throw the word efficiency into every sentence under discussion.  Efficiency is a metric and is easily measured for most things.  If your car is rated to get 20 MPG and you are achieving only 15 MPG, then your car is 75% efficient as it relates to its gas mileage. Efficiency has its counterpart, however, and this is waste.  Many people will tell you lean is about eliminating waste, but that is not entirely true.  Lean is about improving efficiency, and waste elimination is typical the least expensive, most effective way to improve efficiency, but its not the only thing.  Thus, don’t focus soley on waste elimination, but on the improvement of efficiency itself.  For developers, obvious waste is easy to spot.  Phone calls, emails, ESPN.com and things of the like are main culprits.  You have to stop and ask yourself and evaluate each activity: does this activity help me achieve my goal for the day as it pertains to adding value to my client/product/service etc.  Identify – correct – sustain. Kanban, as Dave has been implementing, is one system that helps with waste elimination by having a feedback loop and a continuous work flow by pulling downstream from upstream and current status evaluations.  Other methodologies have different principles behind them, but to achieve the same goals, and I will be talking about those as they each are forms of lean used to Identify Inefficiencies – Make Corrections – Sustain Positive Process Improvements. Lean literature is everywhere.  Take some of the keywords I’ve talked about here and search the web for them.  You’ll find lots of great information. Posted Aug 28 2008, 08:50 AM by Raymond Lewallen with 4 comment(s) Filed under: Lean

• The Fly in the Soup of the Iteration

  Where do bugs fit into your iterations?  This is a discussion I’ve had on many occasions with many different people.  Laribee mentioned they work bugs as soon as they come in.  I believe Bellware told me the same thing.  Provost and Newkirk both told me they get bugs prioritized into the backlog along with everything else as they come in, and they get estimated and put into a specific iteration along with the stories. I’ve tried it both ways.  On the same project even.  We have gone from working them into the iteration, to doing them when they come in, back to working them into the iteration.  We weren’t as successful as we would have liked either way.  Bugs are always hard to deal with, because you don’t exactly know what’s wrong and everything is just guesswork until you go in and look.  And by the time you go in and look to see what could be the problem to estimate how long its going to take to fix it, you find out the majority of your bugs take a change to a single line of code (of course, write your unit test first to simulate the bug and fix the code).  90% of your time is spent figuring out what is causing it.  This is where the estimation of bugs has to hit, on the figuring out, not necessarily the fixing. So how to handle this?  Well, you have to mix together a few different strategies in reality.  Some bugs will come across in the bug tracker as high priority, things that are hurting the production system and must be resolved within the next few days.  Many others will not be as high priority.  What my team does now, and it has worked very well, is when a critical bug comes in, the next person to finish a task will pick up the bug and work it.  All other bugs go into the backlog.  At any given time we have between 10–15 bugs in our backlog.  These are bugs that get worked on Friday mornings and afternoons as the iteration winds down and stories become completed and resources become available.  This has had very little impact (no noticable impact, actually) on our velocity and backlog curve.  So in the end we are not really estimating bugs.  For metrics purposes, we only keep track of a bug count, not an estimated velocity of what it would take to resolve a stream of bugs. Short iterations, another topic I’ve been meaning to talk about, certainly helps deal with quick turnaround on high priority bugs.  If you are working 4 week iterations, the turnaround on a bug is horrendous unless you branch, resolve, merge… puke.  Either way, its still several days to get the bug out at worst case, which is no different than just working 1 week iterations. Posted Aug 01 2008, 10:27 AM by Raymond Lewallen with 5 comment(s) Filed under: Agile, Alt.Net, Lean, Scrum, TDD

• Getting Done the Lean Way

  Something I’ve been thinking about lately, as I’ve been going through reams of paper on lean, kanban, kaizen and Toyota Production system concepts, is how the definition of done differs from that we are used to in Scrum. In Scrum, the product owner gets with the rest of the team and the come up with a definition of done for the particular project.  What done means is essentially the responsibility of the product owner, but its an exercise done by the entire team.  What done means on one project might not be the same definition of done for another project you work on.  This is an allowance in Scrum. In lean, I think I’ve decided that all lean projects have the same definition of done.  Lean is about value, flow and waste elimination, in that order.  With value being the primary focus of any lean organization, the word done must correlates to value.  Thus done can be defined partially as ROI if you want to look at it that way, but something is done the moment value is achieved.  This is the reason why waste elimination is such an important part of lean concepts: its a way to reduce the time it takes to get something done, thus reducing time it takes to provide value. Naturally a product evolves over time, but in many cases, there is an immense amount of value in getting a product out to market, even though its not your final vision.  This is true for every product I can think of.  You think Toyota waited to put out the Camry until they thought it was perfect?  Of course not.  However, the value in getting the car to market given the state of everything, made sense and provided a lot of value.  We view things in software a bit differently, especially in non-Agile circles, but the same holds true.  Lean software’s doneness is the moment it can provide value to its customers/owners. As the people who write software, we might not always be aware of the value a product provides to its company, thus we might not understand why certain feature sets are created before others and it might not make sense to us.  I’ve never been an end consumer of any software I’ve been a part of writing in 15 years.  HR, PR, marketing, accounting, etc.  These are the people who are most likely to understand the value to its highest degree.  Its our job to do work, evaluate cycles, make changes to eliminate waste and continuously improve our processes and reduce the time it takes to provide value. Posted Jul 31 2008, 09:00 AM by Raymond Lewallen with 5 comment(s) Filed under: Agile, Alt.Net, Lean, Scrum

• There is too much money to be made in software development

  Its true.  Too much money is available to IT. As a business with too much money assigned to an IT budget, you’re allowed to have teams completely fail, miserably, and when they do, you just throw more money at it.  Lack of money isn’t the problem.  The failures will still exist. Mediocre developers can make too much money.  Enough money so that there is no incentive for them to be better at their jobs.  To improve.  They are satisfied with the amount of salary they receive, and do not feel compelled to improve as the amount of money they would receive in addition isn’t enough to justify the amount of effort required to exist in a zone of software excellence. The market is saturated with mediocrity, and at a high price.  I’m not going to start repeating myself here; those several sentences above pretty much say it all.  Too many developers don’t have incentive to improve their processes and abilities because they are overly compensated for their skills.  Do they deliver some sort of business value, eventually?  Probably.  And too many of them do it as consultants, write shitty software, deliver working software that nobody in the world can come in and understand what the hell is going on in the code.  Business are blind to this aspect of the software development lifecycle: solubility (thanks Scott) and maintainability.  Make it work, at any cost, and move on to another paycheck.  This is the world we, as software developers, are living in. What is the rememdy?  How to we improve this?  How do excellent software developers make businesses wake up and take notice to the wool over their eyes?  Do I write awesome software?  Certainly not.  There are occasions where some of the decisions I make should be exposed for what they are: poor decisions.  I do what I can to expose them and make them visible so that all involved can learn from my mistakes.  Perhaps I don’t do enough of this, because, after all, my job and reputation is at stake.  At the same time, I feel a moral responsibility to expose myself.  I need to improve, but the software community as a whole needs to improve even more. Posted Jan 22 2008, 07:59 PM by Raymond Lewallen with 79 comment(s) Filed under: .Net Development, Agile, Alt.Net, Featured, Generalities

• Are you a problem solver or a developer?

  I had this conversation with some friends on Twitter about a month ago and have been thinkinng about it ever since.  We are all professionals, but professional what? I have come to the conclusion that I am a problem solver.  That’s my business.  Whether its process management, software architecture, personal growth for my development team or trying to keep my daughter from stealing my son’s toys, I solve problems.  Software development is my tool (except for the stealing part.  I use my daddy voice for that). One thing I have learned from BDD is that developers spend too much time thinking about technical implementation details rather than the problem at hand itself.  I am continuously working with my current team to get them all to adjust to this way of thinking: think about the problem.  What are we trying to do?  We’re not trying to write software, we are trying to provide value to our customer, and we achieve that through software.  Adopting the context/specification style of testing has helped me evolve even more into a digging into a deeper understanding of what the problem really is, what context does the problem apply to, and what are the specifications that are proof to show that a solution can be demonstrated?  You MUST think about these issues before writing any code, and too many developers just want to code without fully understanding what the problem is.  ONLY when you fully understand the problem, can duplicate the problem and demostrate it with specifications, can you start thinking about technical implementation.  Naturally, you have to have some sort of roadmap, an idea for system architecture, think about non-functional requirements, and that’s all expected and necessary. But when it comes down to coding a piece of behavior into a system, too many developers are still just jumping in and coding.  Even when writing unit tests, developers are thinking about the techinical aspects of the system and often write poor unit tests.  I’ve been there.  This is why I feel TDD is an ancient and outdated craft.  TDD does not do enough to force developers to really focus on the problem and gain a full understanding of it prior to coding.  I feel BDD helps achieve this. I haven’t posted anything on what I’m doing with BDD because you can search CodeBetter for it and find information from several of the bloggers, all of whom I’ve spent a considerable amount of time with to help me evolve to be a better problem solver, by way of writing software. We need to focus on the problem at hand, and let the technical details and implementations evolve from specifications and that demonstrate the problem.  C# is easy.  Correctly solving the problem your customer is having and delivering the appropriate behavior is much more difficult, so there is where your time needs to be spent: understanding the problem.  Once you fully understand what you are trying to deliver and have specifications within context to demonstrate this, the technical solution will be clear, simple and right in front of you.  Let it evolve from that.  The technical implementation is secondary to the understanding of the solution. Posted Dec 27 2007, 12:23 PM by Raymond Lewallen with 26 comment(s) Filed under: Agile, Featured

• LOL You have got to see this

  This was just WAY TOO FUNNY to pass up sharing with everybody! Sorry for the link post, but I couldn't stop myself.  Check out the name of the ship! http://news.bbc.co.uk/2/hi/americas/7108835.stm Posted Nov 24 2007, 09:43 AM by Raymond Lewallen with 8 comment(s) Filed under: Generalities

• How do you clean up the files in a project quickly?

  Put your hands on your keyboard, don’t touch the mouse. CTRL-ALT-L; Down Arrow (to a file), Enter, CTRL-ALT-F, Enter, (F12, Alt-Enter, Enter (repeat all necessary loops)), CTRL-ALT-F, Enter, CTRL-S, CTRL-F4 Repeat until you reach the end of the file list.  *note* you have to have Resharper.  If you don’t, shame on you.  Your job is harder than mine. Update:  This is using IntelliJ mappings.  The key sequences are as follows: CTLR-ALT-L – move from editor window to solution explorer. CTRL-ALT-F – reformat code F12 – move to next error/problem/issue ALT-ENTER – suggestions for fixing issue CTRL-S – save the file CTRL-F4 – close the fil Posted Oct 04 2007, 01:04 PM by Raymond Lewallen with 17 comment(s) Filed under: Generalities, OOP

• As a scrummaster, scrum is not my first option to a new client

  I had this discussion briefly at BarCamp Dallas yesterday.  The question came up as to how do I describe scrum to my client? When going into a new client, I don’t.  There are a lot of companies out there that are reading about scrum and learning scrum on their own, and then want to hire somebody to come in and implement it.  And if they bring you in, the thing you shouldn’t do is start implemeting scrum. I would argue that most established development groups have a process model that they are following, and do it reasonably well.  The real question you ask first is what is wrong with your current process?  What is and is not working?  Are you delivering stable software releases?  On time?  Within budjet?  Desired functionallity for the stakeholders and users?  I've gone into clients who want to implement scrum, yet are able to answer these questions with answers that are indicative that they are operating very well under their current process, but might just need a few tweaks, not an entire change to how the lifecycle in managed. Very often, its just a matter of finding out what is wrong with the current processes, and find a way to fix them.  Scrum can be a major disruption to the flow and efficiency to a partially successful development team.  Implementing scrum into an existing team, which more times than not requires and entire mindshift and replacement of most of their current processes, is difficult for the team, for management, for stakeholders, etc. Bottom line is don’t go into an existing team and just implement scrum because they think its going to solve their problems.  Scrum is much more about making problems transparent so that you are forced to face them and solve them by other means.  Scrum is not necessarily a solution to many of the problems you have.  It certainly helps clarify what problems are lurking within your team that you just may not be able to recognize. Scrum is my preferred process management solution.  Its not right for all teams and not necessary for all teams.  Help your client to clarify their problems and find ways to resolve them within their current processes before completely changing how the lifecycle is managed. Posted Sep 30 2007, 02:42 PM by Raymond Lewallen with 9 comment(s) Filed under: Agile, Alt.Net, Featured, Scrum

• Alt.Net does NOT equal Anti-Microsoft

  I've had this post sitting in the queue forever.  Not forever, but about 2 months.  Before I start, I'd love to be able to go back and quote the mass amount of Alt.Net posts that have come out of CB over the last few days, but to be honest I don't have time to read them right now.  I'm the busiest person I know and can't even find time to read. This post originates from the Oklahoma City CodeCamp we held back in July, where we had a Microsoft technologies track, and an Alt.Net track.  The Microsoft track consisted of things like Silverlight, WPF, WCF, C# 3.0 and the like.  Alt.Net consisted of BDD, TDD, pair-programming, DDD with NHibernate.  After the code camp was over, I had specific feed back come back to me that people stated that they loved the Microsoft and Anti-Microsoft tracks.  WTF!?! Disregard the fact everybody in the Alt.Net track used Visual Studio.  They all ran on Windows.  They all programmed in C#.  How do concepts surrounding great principles and practices around software development get viewed as being anti-Microsoft?  Seriously? This concept completely confuses me.  What mindset are the people in who make these statements?  Now I'm not going to go recite what is Alt.Net.  I think the community is flooded with this information right now and you probably know what those of us close to the idea are trying to convey.  How can you look at what Alt.Net portrays and publicizes, and believe these are things that go against what Microsoft tries to do?  Microsoft is in the business of making money.  They give us tools, some good, some bad, to help us create software faster (ok, maybe a few pieces help us deliver better software).  And we buy them.  We may or may not use Microsoft tools, and certainly shouldn't limit ourselves to a single vendor, framework, concept or methodology.  Alt.Net is about creating better software, and using the right tools and practices to help you accomplish this, be it Microsoft or not. Alt.Net and Microsoft should go walking down the aisle together, get married, and produce offspring that carry the dominant genes of both pools.  They compliment eachother.  They should reside together in your head and in your toolset as you accomplish the task of creating better software.  That goes for Alt.Net + any tool vendor + any methodology that you and your team understands, can grok, use and make your team the most productive team it can be and deliver business value.  I believe most of the folks close to Alt.Net embrace Microsoft and what it tries to do, even if some of what it does is poorly thought out and even unusable to some people, IMO.  Microsoft is getting better at listening and understanding the developer community.  Many Microsoft folks are coming to the Alt.Net conference in Austin in 2 weeks and I think its going to be valuable for all involved. Since I don't know who made the remarks specifically (they came back to me anonymously, and it was several remarks, not just one person), I can't go to them and start this discussion.  I have to bring it up here and see what comes of it to help me and my understanding of how I can help convey the ideas behind Alt.Net better to my community without somehow having them perceived as anti-Microsoft. Posted Sep 24 2007, 08:08 PM by Raymond Lewallen with 24 comment(s) Filed under: .Net Development, Agile, Alt.Net, Featured, OOP, Patterns and Practices, TDD

• Welcome Dave Laribee to CodeBetter!

  So this is a no brainer.  Where is there a better fit for Dave Laribee other than CodeBetter?  So many of us share the same ideals, the same goals, suffer the same pains and have common solutions for problems we encounter, that it only made sense that Dave Laribee join us at CodeBetter, where a family exists that he can join and feed off of, and provide support to.  Dave is a great asset to the software development community, and thus a wonderful addition to the CodeBetter community. We welcome Dave Laribee, the man most popular for his 80s style hair and attire, flashing his legs while wearing his daisy dukes (I have to photos to prove this), but you may also remember him from a term he coined earlier this year: Alt.Net. Welcome Dave!  Its great to have you! Posted Sep 17 2007, 10:09 AM by Raymond Lewallen with 8 comment(s) Filed under: Generalities

• Reminder that the Oklahoma City Code Camp is this weekend!

  For those of you in the area, just a reminder that the code camp is this weekend and we have a few of our very own CodeBetter guys (Jean-Paul Boodhoo and Scott Bellware), along with Dave Laribee, David Walker, Tim Rayburn, Cory Smith, Ben Shierman, David Nicollette and Eric Stott.  Our keynote speaker is the general manager of the .Net Developer Division at Microsoft, Jason Zander! View the agenda here, and be sure to register if you are coming! www.okcodecamp.com Posted Jul 26 2007, 05:17 PM by Raymond Lewallen with 5 comment(s) Filed under: .Net Development, Continuous Integration, Extreme Programming, Generalities, Patterns and Practices, TDD, User Groups, WPF

• What I am doing to become a better developer

  I'm happy to oblige Jeremy on answering his tag on this meme that was started recently. For me, the first and best step to take in becoming a better developer is that daily realization of how much I don't know.  When I read blogs or talk to other people or read a chapter in a book, its just overwhelming how much information goes along with this career path.  Perhaps that is wehy recently I've been really stirring the pot in my head and really thinking about how much longer I'm really going to write code as my primary job function.  I'm always going to write code (everything I hit the W key on my keyboard an E comes out with it and its really starting to piss me off) because I love the problem solving that goes with being a developer.  I love refactoring code.  I wish "refactorer" was my official job title and primary job function.  I think its fun as hell and resharper helps to make it fun.  However, I really want to move towards more of a coaching role, where I can sit and code with other team members, do that for a few months and then move to a new team.  I think I'd really enjoy doing something like that.  Now the question becomes am I good enough of a teacher to do that?  My big problem is I'm not really a people person when it comes to work.  I can be rude and condescending at times, and I am making an active effort to curb that type of behavior when I sense it happening.  I'm not going to be a successful fulltime coach until I can handle some of my attitude issues.  I also can be arrogant and display egotistical behavior, but I'm fine with that.  I feel it almost necessary to be able to voice your opinions, be confident in yourself and your arguments, and fight your battles well.  That comes off to many people as elitist, and so be it.  At the same time, accept defeat graciously and be humble.  There's always someone nearby that's going to know more than you do about a given subject matter. Honestly, I really am very busy lately, when I'm not procrastinating (see below).  I have a manical almost 4 year old who is just totally messed up in the head and is a freak of nature.  I honestly don't understand how kids find the energy and complete random behaviors that they do.  She's crazy.  She really is.  She gets it from her mother.  I spend a lot of time with her because we have a 3 month old at home now too and my stay at home wife needs all the breaks she can get.  I take my daughter out on the weekends and we fish or swim or *cough*dropheroffatgrandparentswhileIgotothecasino*cough* or just walk around the mall and have lunch.  I enjoy spending time with my daughter, and that is, I'm sure you would all agree, more important that anything that I could do to evolve myself as a developer.  I have to make sure I'm evolving as a father first, then take care of the secondary things.  Raising my children is my real career.  Getting to write software for money is just a perk, because its my hobby anyways. So back to the original topic at hand, here's my list of things that I want to address over the near future to become a better developer: Things I Should Do Same as Jeremy, work on planning and estimation skills.  I attended a 2 day Mike Cohn course, and it was awesome.  He's a great teacher.  I want to spend more time with guys like him who have an incredible amount of real world successes and failures to draw on when coaching.  I need to pick up everything he's and a few others have written on agile planning and estimation. I started my career in the database.  I was a DBA for many years prior to really getting heavy into programming.  Since Sql Server 2005 came out, I've really not done much database work and I'm missing it.  I love design, modeling, tuning and other developer-based tasks.  Its the actual admin crap that I really never liked.  SqlSvr2005 has some really awesome features, and I was doing a lot with them back in 2005.  I want to get back into databases again.  Those of you who were reading this blog back in 2005 can probably recall that well over half of all my posts were database/T-SQL related. I don't know Ruby.  Never even looked at it.  Boo as well.  I keep reading so many awesome things, but I just... can't... squeeze...more time into my day.  I need to learn both and what they can do for me. AgileDevelopers.Org.  I need to get something done with that.  I started the Oklahoma Agile Developers group, which is headed by a committee comprised of .Net, Java and Ruby user group leaders and practitioners.  My focus is a language agnostic workshop group.  If anybody wants to help with the website and get something going with me on a worldwide scale through the website, or if you have other ideas, just let me know.  I'm not sure what I want to do with the website yet, but the possibilities are awesome and no doubt some things can be done with it from a shear repository viewpoint that would certainly help me become a better developer if the information were available and easily accessible and organized.  But, that's what google is for. Quit procrastinating.  I'm normally not bad about this, but I've been so incredibly busy this year that I've been finding myself just stopping and doing nonsense stuff more often that I should.  Fishing every weekend does not count as nonsense stuff.  That's what I do to maintain sanity.  But when I pulled out the old super nintendo last week out of the attic to play Gauntlet Legends and Castlevania, well, I'm not getting many books read, posts finished (I have well over a dozen unfinished blog posts) or emails sent. Things I Want to Do Spec#.  I've played with this in the past, and really liked what its does for DbC software development.  I want (damn you W key!!) to get back to playing with it again and really get into it.  Greg Young and I have occasional conversations about it and his enthusiam and knowledge about the language extension keeps my hyped up about it.  Thanks Greg! F#.  Functional languages in general really.  I've talked to several people who really dig F#, but on the same token they understand functional programming better than I do, so I have some work to do.  With Spec# I understand it, grok it well, have written some apps utilizing it and knowe where I can go with it.  F# not so much.  I hear a lot of talk about possibilities with F#, but I just don't have the knowledge to think about what it can do for me, and I need to fill that gap. Get back to blogging more frequently.  Lately I can't even read all that I want to, much less find time to blog.  When I was blogging more often, I was spending time researching issues, playing with other tools, learning new things about the CLR and just having fun investigation the CLR.  If I could find time to blog more, I would be doing those things, which no doubt improves my abilities as a developer. Not much else I really want to do.  I'm really comfortable with what I have going on right now.  I do need to get out of my C# hole though and get back to expanding my horizons and widening my visions of what is possible and easier to do with other languages and concepts.  I spent most of last year working on concepts such as DDD and then BDD (both of which I am continuing to educate myself).  This year I haven't done anything to expand myself in this developer career of mine.  Oddly enough, I've been comfortable with that this year.  Maybe 13 years into it, my conscience decided its time to take a year off from cramming languages, concepts, methodologies etc into my head. Things I Won't Do Stop my community involvment.  If at all possible, as long as its not at an expense to my family, I will continue everything I do to help my community evolve to become better developers.  I've done 9 speaking engagements this year to date, have 7 more scheduled, am planning a code camp (www.okcodecamp.com), and am on the steering committee or head of the developer or agile track for 3 other conferences this year.  Its a lot of work, a shitton of emails but a lot of fun to see those things be successful.  Oh yeah, I'm also the president the Oklahoma City Developers Group and founder/president of the Oklahoma Agile Developers group.  I really enjoy helping the community, which has a lot to do with my thoughts on a slight career change to fulltime coaching/mentoring with some development, rather than full time developer with some coaching/mentoring.  I feel my community involvement and relationships that are built help me be a better developer because of the knowledge and perspectives I gain via conversations. Although at one time I wanted to get into them, WPF, WCF and WWF are not in my plans for the future.  Not to say I won't learn any or all of them eventually (I own several books on each subject, not opened a single one of them) but for now its hard enough just staying up with domain knowledge.  I'm consulting to oil and gas industry and its a big change for me.  I spent 4 years in aviation and felt extremely comfortable with my domain knowledge and ability to find answers.  I'm in a completely new to me industry now and I spend my time learning about it, not new technologies that I obviously don't need to solve my design issues.  Maybe they are better solutions in a few cases, but the tradeoff against the learning curve involved just isn't there. Tagging these folks K. Scott Allen (its a given that I always tag K. Scott when these things come around, I'm sure he appreciates it more than I know), Daniel Moth, Phil Haack, Oren Ellenbogen Posted Jul 11 2007, 11:17 PM by Raymond Lewallen with 15 comment(s) Filed under: Generalities