Catbert Strikes Again

This cartoon is so evil it’s borderline not even funny.  I guess sometimes the truth really does hurt.

Technorati Tags: Dilbert,Economy,Recession

Recent travels…

This month I took a short vacation.  We went to Las Cruces, NM for some fun in the sun.  We played a couple of rounds of golf, and romped around the desert for a few days.  Specifically, we went to the Gila Cliff Dwellings and Carlsbad Caverns.

Check out some of my favorite pictures from this trip in the photo album below.

View Full Album

 

Using Photo Albums in Windows Live Writer

View Full Album

My picks from “97 Things Every Software Architect Should Know”

Recently I read a great book called “97 Things Every Software Architect Should Know.”  It is collection of short mantra’s, stories, and examples of what good architects should know.  You could basically consider the book the be “guidance” or “best practices” for how to be a good software architect.  The contributions to the book were made by industry leaders and fellow architects.  As I read the book, I found myself agreeing with most of the items in the book.  Some items stood out more than others.

In this article, I have documented my favorite things that every software architect should know.  Some of these I already practice, and others I need to work on.

1. Communication is King: Clarity and Leadership, its Humble Servants – by Mark Richards:  Mark says that clarity and good leadership are the keys to successful communication.  He says to leverage short 1 or 2 page documents, simple diagrams, and white boards to provide a clear vision.  He also says that you can be a good leader by bringing developers into the architectural discussions, get their buy in, and involve them in the big picture analysis, whatever you do, don’t keep them in the dark.  Since they will be doing most of the work, you need them on your side. 
2. Seek the Value in Requested Capabilities – by Einar Landre:  Long story short, if you truly understand “why” a requirement is valuable to the customer, then you should be able to architect a solution that addresses the root problem.  Understanding the value also helps with prioritization.
3. Simplicity Before Generality, Use Before Reuse – by Kevlin Henney:  Basically, Kevlin says the goal should be to provide a simple solution that solves the problem.  Then, once you understand the problem, and you have provided a simple solution, you can then go back, if need be, and make it more general.  I have caught myself thinking about what patterns I will use before I even have the unit test written.  Who said I needed a pattern anyway?
4. Architects Must Be Hands On – by John Davies:  John believes that a good architect should be able to fulfill any of the positions on his team.  He need not be an expert on all areas but he does need to have an in-depth understanding of all of the components.  I agree that this is an essential trait of a good architect.  Lead by example has always worked for me. 
5. Continuously Integrate – by David Bartlett:  David basically says that using CI (aka build automation, etc) is good.  I firmly agree.  The highest bug count that I have had on my current project, that has been running for 18 months is 20 bugs total.
6. Understand the Business Domain – by Mark Richards:  If you are not interested in understanding the business goals, business problem, business requirements, and the industry trends of the business domain in question, chances are you are not interested in being an architect.  Personally, I take advantage of every opportunity I get to talk with the General Managers and Executive Staff so that I can understand more about the business and the industry.
7. Scope is the Enemy of Success – by Dave Quick:  Since we are all developers, we know this to be true.  Dave makes a great point that I had not considered “Doubling a project’s scope often increases its probability of failure by an order of magnitude.” 
8. Software Architecture has Ethical Consequences – by Michael Nygard:  I beleive that some of my personal core values are honesty and integrity.  Michael points out that we have a responsibility to our clients to recommend and do what is right for our clients.  If we, as architects take short cuts for our own sake, then we are cheating our clients.  Personally, if our clients insist for us to take shortcuts, I believe that it is time for me to look for another employer.
9. Skyscrapers Aren’t Scalable – by Michael Nygard: This is one of my favorites.  Long story short, “Commercial Launch” or “Big Bang” releases are bad.  Michael says “Traditional “big bang” deployments are like stacking up a pile of beams and girders, throwing them into the air, and expecting them to stick together in the shape of a building.  Instead, we should plan to deploy one component at a time.”  He then goes on to say “It’s OK to release an application that only does a few things, as long as users value those things enough to pay for them.  In fact, the earlier you release your application, the greater the net present value of the whole thing will be.” 
10. Fight Repetition – by Niclas Nilsson:  Niclas says that “Duplication is evil and repetitive work slows down development.”  It is our job to reduce this duplication.  If you find your developers copying and pasting code, you should do something about it.  If you find your developers hand coding the same 5 stored procedures for every table, you probably should look at a code generator.
11. Empower Developers – by Timothy High:  Put things in place that help your developers do their job better.  Such as, keeping project managers out if their hair, allow them to make their own decisions, give guidance about naming, code standards, and best practices.  Reduce their paperwork and office chores.  Help them get better tools and workstations.  Buy books, help them learn, send them articles, do whatever you can to help them learn and grow their knowledge, skills, and abilities.
12. Record Your Rationale – by Timothy High:  When I read this, I thought this was a great idea.  It basically says to document why you have made the decisions that have been made.  Thinking back on my current project, I know why we have made the decisions that have been made over the past 18 months, but others on my team do not.
13. Pattern Pathology – by Chad LaVigne: The point to be taken away here is to know your design patterns, but know when to use them and when not to use them.
14. Focus on Application Support and Maintenance – by Mncedisi Kasper:  The main point here is that you can’t bring down production to test a bug fix, and you cant run the debugger in production.  So, make sure you have the logging and monitoring tools in place so that your operations people can help you figure out what went south of the border.
15. Make Sure the Simple Stuff is Simple – by Chad LaVigne: I cannot agree with Chad’s statement more “”When you try to guess at future requirements, 50% of the time you’re wrong, 49% of the time you’re very wrong.  Solve today’s problem today.  Get the application out the door on time and wait for feedback to generated real requirements”
16. Before Anything, and Architect Is a Developer – by Mike Brown:  To me this translates into leading by example, practicing what you preach, and putting your money where your mouth is.  Mike makes a great point… “If you can show your developers that you’re not just some pie-in-the-sky daydreamer who can’t code his way out of a paper bag, you’ll hear less grumbling about the hoops you’re “making” them jump through to get data to show on the page when “I can get it done in less time by just binding a dataset to a grid.” 
17. You Have to Understand Hardware, Too – by Kamal Wickramanayake: If you are going to propose software solutions for your clients, you need to have an understanding of the hardware required to run the solution that you are proposing.  If you are too far out of your realm, you also need to be able to tell your client that you need to involve an infrastructure architect to sanity check or help provide the hardware solution.
18. Shortcuts Now Are Paid Back with Interest Later – by Scot Mcphee: This is self explanatory.  As features become the basis for new features, if you have taken shortcuts in your initial architecture, it will cost much more to refactor the bad architecture into good architecture, because the collateral damage is large.  I can think of a few places in my current project that are like this.
19. If You Design It, You Should be Able to Code It – by Mike Brown: Enough said.  However, personally, I should help developers that I work with understand how to code it vs. just doing it myself.
20. Choose Frameworks that Play Well with Others – by Eric Hawthorne:  Eric is basically saying don’t choose frameworks that require you to “Become a fundamentalist in the framework’s religion, or limit your choices of other frameworks to those of the correct denomination.”  Basically, he is saying leave the framework baggage on the curb.  Some examples of heavy frameworks that come to mind for me are “DotNetNuke”, “CSLA”, “CAB / WPF-CAB / SCSFContrib”.  On the other hand, some more lightweight frameworks that come to mind are “Prism”,”Rhino Mock”, “Microsoft Enterprise Library”.  If you do have to choose a heavy weight framework, make sure that you can at-least isolate it or make sure that it performs most all of the functionality for your solution that is required.  For example, I prefer LLBLGen Pro ORM tools for data access, but it provides 100% of my data access functionality and it is isolated to only the data access layer.
21. Pay Down Your Technical Debt – by Burkhardt Hufnagel: Sometimes you have to make “Hot fixes” to code in production.  This typically causes technical debt.  If you agree to do this, make sure that you get buy in to start reducing the debt incurred by this hot fix.  Start reducing the debt immediately after the hot fix goes into production.  If you don’t fix these things and keep hot fixing, you end up paying much more interest over the long haul.
22. Don’t Be a Problem Solver – by Eben Hewitt: Honestly, it took me a few passes through this one but I finally got it.  Often times, we go straight into problem solving mode.  We focus right in on the problem and fix it.  Rarely do we sit back and “Imagine what the solution would look like if we didn’t have the problem.”  Yes, ultimately it is our job to fix the problem, but the best way isn’t always the one that addresses the problem directly.  Maybe the problem is caused by collateral damage from some other component that is going wrong.
23. Find and Retain Passionate Problem Solvers – by Chad LaVigne: This statement is self explanatory.  Find people that are passionate about what they do, just because they have an MCSD doesn’t mean they enjoy what they do, nor does writing an API.  Chad points out that a measure of good engineer is their response to this question: “Given the chance to redo your last project, what would you do differently.”  Chad also makes the point “Finding great developers is difficult; letting people know they are valued is not.  Don’t miss simple chances to build morale and boost productivity.” 
24. You Can’t Future-Proof Solutions – by Richard Monson-Haefel: Basically this is saying that you cannot predict the future, nor can you control it.  What is cutting edge today, will be obsolete tomorrow.  That being said, choose the technology, tool, or framework that meets today’s requirements.  Richards advice is to “Choose the best solution that meets your needs now, because anything else will not only be the wrong choice tomorrow, but the wrong choice today.”

This book is a great read and one that I recommend that all aspiring engineers read.  You can pick up a copy from Amazon.com or your local book store.

Technorati Tags: software architecture

Who needs stakeholders, just make a decision…

 

 

I suppose that Dilbert could finish in two weeks.  All he needs to do is document his plan and send it to the stakeholder, and make sure he does what’s in his plan.  Sure he may have to deal with comments like “That’s not what I had in mind” from the stakeholder, but, on the other hand, he would be done with what he decided to do.  If I were Dilbert’s supervisor, knowing that the stakeholder didn’t make himself available, I would credit Dilbert for making the decision and following it through.  Too bad other supervisors, project managers, and stakeholders don’t see things like that.