Will post follow up later on what I learned.

For my $.02, I was a bit worried that it had been blowing past breakpoints without warning.

For those of you unfamiliar with Mono, this is a cross collaboration endeavor. Its purpose is to allow .NET (particularly C#) framework apps to run on *nix. With the primary benefit being that you can write code in keeping with Microsoft “standards” while letting developers focus on code and less on platform.

I know, I hear the question “But Java already does that” and of course there’s never one tool or one solution that will make every person happy. But, this works pretty well for those working in Windows and Linux.

MonoDeveloper Tools

You can also pull the latest branch:  $ svn co svn+ssh://username@mono-cvs.ximian.com/source/trunk/monodevelop

I’ve submitted a speaking proposal on scalable design.

Overview:
The road lay ahead, success or failure, and how you respond early will help determine your outcome. With much planning, thought, and expense you’ve built the greatest tribute to innovation, Solving a problem, filling a need or answering the call of excellence. All worthy pursuits in the attempt to obtain your goals and roll out your product or solution. Success!! People are using it. One problem, people are using it.

You suddenly realize that the hardware isn’t adequate to meet the need. Throw more hardware at it, great but is that the problem? Does your solution adequately scale? Would you benefit from RESTful, load balancing solutions? How much can you achieve and hope to achieve with development best practices.

As a software engineer, architect, CFO or CIO do you have a clear road map of what your future looks like? Many of us have seen Field of Dreams and are familiar with the quote “If you build it, they will come”. This can be a boon or a bust based upon your ability to ramp up and leverage technology and forward thinking solutions

Solution:
Success is more than having a project completed. It is also knowing when and how to successfully apply the litmus test to your design patterns. As well as your architecture as a whole. Join me while we separate fact, from fiction, and discuss the best approaches for the task at hand.

Stardate -319008.87 and, it has come to my attention that there is a web scripting engine largely ignored. While I have been aboard the starship U.S.S. Enterprise  for many years, and web centric development since -323906. In my own mind, I had learned all my tricks from Montgomery Scott. I had been able to avoid the PHP quadrant while keeping the dilythium crystals charged….

OK, admittedly this sounds increasingly like a bad Star Trek episode gone entirely awry. Let’s try this again. The year is 2004 and I have been working with web related technologies for a number of years. Not the least of which was PERL and mod PERL. During this time I had heard more and more about PHP and tended to scoff at it. You know, the typical “Well it isn’t PERL (or insert language)” sentiment, and it would be fair to say that was a feeling that was shared by many web masters and developers of the time.

During this time I had to try out PHP for an API to a mortgage product solution. Prepared to be skeptical, ready to be proven right,  and certainly ready to poke fun. Alas, this was not to be as I actually felt a tinge of respect for this language. As time went on, my skill in, and respect for PHP grew. Now this was PHP 4.x and noticed right off that it lacked various features I would deem essential.

Setting all of the preconceived notions aside, I found that I could prototype an MVC architecture very quickly. Over the next few years, I wrote and re-tooled a lot of legacy code. Finding efficiencies, bottlenecks, shortcomings and it would seem everything in between.

Present day, I actively use PHP 5 and heavy Object Oriented design patterns. This works very well with my development style, after all why reinvent the wheel if you only need to inflate the tire. So, the other day it dawns on me that I know I have all of this experience. The question is of course how can I stand out from the rest of the crowd?

First thoughts of course were, “Ohhh, I could wear some cool t-shirts to showcase my geek factor”. Immediately followed by, “I could say I have a lot of experience”. While both of these I am sure have some unrealized merit the real answer lay closer to the surface.

PHP-ZCE – No, it’s not a contagious influenza strain. Nor would it be a new medication to help with rickets. Rather, the company(Zend) that controls PHP has offered a way to certify your knowledge, value and worth. Sure, I know how much I know or think I know but it’s a dose of reality to think about truly proving it.

I have signed up and will be going to a certified testing center. One could say that it will provide some value or worth to me. Really what I hope is to encourage the trend of holding fellow PHP engineers to a higher standard. You say you’re worth more? Your value isn’t realized? Prove it. Join me in raising the bar.

I’ll keep you posted…

• Part 1 – What are stored procedures and how do they work?
• Part 2 – Determining when to use. What are the benefits, restrictions and so on.
• Part 3 – Extensibility, security and server efficiency

If you have any questions, please feel free to ask. And I will respond accordingly.

Whether you are creating the plan or hoping to rely upon. The moral, always insist upon it being done sooner than later.

Tarantula Hawk is a F/OSS lightweight, database wrapper that provides easy and consistent coding standard. A GUI page allows you to configure, tweak and modify your tables, queries, etc. It is easy to implement and takes about 10 minutes to use. It also allows for dynamic 404 replacement without having to do massive .htaccess additions.

In the meantime, here’s the link:  http://sourceforge.net/projects/tarantulahawk/

Probably everyone has heard at least one of these sayings “customer service is king” or “the customer is always right”. In turn we generally conjure up an image of buying a product from “someone who gets us”. And why wouldn’t we want as a consumer want to receive the best customer experience possible? Whether good or bad we tend to remember our interaction, level of service, quality of product and would we become a repeat customer.

As is often the case in life so it is in business, people talk. If you run a hot dog stand your image and presentation are as important as the quality and delivery of your product. For example: Your hot dog stand, if it has relish spilled all over and doesn’t get wiped up people will notice. If your hot dogs are served cold, or your buns are stale or you are out of mustard. Should you hand a hot dog to someone without placing it into a napkin, it will be noticed.

Years ago when I worked in downtown Seattle, I would take the express bus home. Often times I would work through lunch and have the feeling of hunger set in just in time for my daily retreat to the bus stop. Many a day I would look forward to waiting for the 132 to arrive. More often because I knew it would give me time to consume a tasty hot dog. It was the quality of the all beef dog, the smell, taste, presentation and the attitude that it was served with.

Sure, it was just a hot dog. But it was turned into a memorable experience, each and every time. Why?  When the vendor of that cart takes time to learn your name, recognize that you like sauerkraut. And knows that ketchup should never be found in the vicinity of a hot dog. You form a bond of mutual understanding that transcends any single aspect of the experience.

So, what does a hot dog have to do with outstanding service and keeping a customer happy? I think in its most simply stated form, a hot dog that costs $2.00 or a piece of software that costs $20,000 are the same. Here’s why:

• The vendor must be visible to the target audience
• Offer a product that appeals or fills a need
• Create an experience that is streamlined with as little guessing as possible
• Pricing must be in line with market conditions. A $10 hot dog no matter how great is going to have a smaller market than a $2 hot dog.
• Treat everyone with the same high level of professionalism. Just because you are slinging dogs doesn’t mean that it isn’t a real business. It becomes real based upon how you approach it.
• Consistency is as important as any point mentioned above. Nobody likes to be uncertain how their routine experience will turn out. It just needs to be be good and unfaltering.
• Don’t overlook the little things, include a napkin, keep the condiments clean and well stocked, be proud of the product and stand behind it.
• Encourage the customer to tell their friends about the best hot dog stand in the world.

Ok, it works for a hot dog stand but what about me?

To really stand out and ahead of the run of the mill vendor. You must genuinely care about the product or service that you offer. Strive for mastery in presenting said product and also realize that you are not alone. The competition is also striving to do the same thing and you can only set themselves apart by offering the experience that people will not forget.

OK, great so give everyone service with a smile and they are always right, yes? No! Being too passive can be worse than being apathetic or forbid robotic and disingenuous. Just because a customer thinks they want something a certain way they may not totally understand their request or its ramifications. In software development, I have been asked time and again to write programs in a way that would not make sense. Many times people require guidance in making the best decision and it isn’t always as obvious as it might appear.

Be polite but be assured that you know your product offering. Know the limitations of what you offer and how it can be impacted negatively. Trust that you continue to hone your skills so as to offer the recommendation that best suites the customer. Don’t compromise your belief or quality requirements, it will be noticed.

Finally, don’t be afraid to turn away a potential customer. No, I am not crazy. Obtaining a customer that you can’t help or are not a good match for will end up costing you time, frustration and often money to support them. Not to mention the negative aspect that the customer now has had a less than stellar experience. And after all, people do talk and do you want your business being part of that discussion if it is anything less than the best?

A company that can say “Your request will not produce the result you hope it will. May I suggest a different approach that can save you time, money or hassle?” will be viewed with integrity even if they aren’t happy to hear it. Follow up with someone even if they didn’t become your customer. Be willing to put yourself out there a little and give people more than they expect.

At the end of the day, good or bad the customer experience is like the Faberge shampoo commercial. “”I told two friends about Faberge shampoo and they told two friends and they told two friends and they told two friends”.

There are many approaches that Project Management can take. Many work well, some exceptionally well and yet others fall flat on their face. So what determines success or failure in ensuring a solid, trouble free product launch? If we could in a sentence sum up this requirement it would be: ‘Planning our goals and letting our people work with supervision but not micro-management.”

Common reasons why a project fails:
·  Unrealistic goals of the process/business unit owner.
·  Feature creep – allow the scope of the original project phase to bloat or extend beyond reasonable delivery time.
·  Poor planning of a project plan and the resources involved.
·  A perceived product need that in reality doesn’t meet a need.
·  Junior development staff that receives no direction or mentoring by senior staff.
·  Not evaluating current milestones and being realistic.
·  Poor communication skills – It is easy for a non-technical person to say “yes” and in reality they think they are agreeing to something totally different. And can be understandably confused by the lack product fulfillment because of errant exchanges.
·  Not managing your customer relationships. It is far better to over communicate early than to wait until a deadline has passed. This creates frustration, distrust and the perception that your skills and even developers are lacking the necessary skill to meet the required need.

Reasons why a project will succeed:
·  Effective planning and understanding of goals.
·  Consistent monitoring of progress and adjusting milestones based upon current status.
·  Mentoring junior staff to become better employees. And in turn increasing the morale and unity of a team.
·  Keeping surprises to a minimum. If you are two days from going live with a product launch. The worst thing you can do is to add in untested features. Because these are inevitably the features that will blow up.
·  Surrounding yourself with the best talent you can find. And part of that process is continual growth and education. This education can be as simple as role playing, code reviews, sitting in on conference calls and learning to interact with clients.
·  Constant communication – if you were building a dam and there was a structural flaw you could correct it early. But if no one tells the engineer and it goes into production there are many potentials areas waiting to fail. Even if a project time line slips it is better to keep everyone in the loop and aware.

Successful Project Planning

Project analysis phase:
·  Determine business need(s). If possible meeting with the business/process owner. Take non-technical requirements and input and accurately convert to a logical blueprint.
·  Decide what are critical items, required items, nice to have and if there is time items.
·  Meet with appropriate key development staff. Discuss project scope and receive input, feedback and pitfalls so that we can deliver the very best solution.
·  Continually mentor staff to refine deadlines, increase quality and accuracy of deliverable(s).
·  Create a planning draft that entails timelines, budget constraints and staffing resource availability all based upon real world SCRUM milestones.
·  Upon agreement or in some cases prior to final agreement. I tend to do mock ups, working prototypes, graphs, charts, etc

Prototype phase:
·  Create working shell, framework, API, etc that will allow other resources to participate.
·  Daily monitoring of feedback, project status, bug tracking, etc.
·  Definitions of what module(s) will accomplish can be completed and their overall functionality reviewed before committing to complete development.
·  Setting the scope of scalability and architecture to ensure the most robust solution feasible

Implementation phase:
·  Continuous tuning and monitoring of time lines and project goals.
· Touching base with the business/process owner and when needed a show and tell to make sure we are all in agreement.
·  Quality assurance testing before we say something is “good”. It needs to be tested, not just by the person writing it who will often time only use it how they designed. For commercial quality, production grade software Q.A. testing and focus groups with people who are NOT part of the process can lend invaluable insight.
·  Ongoing bug tracking, resolution and ultimately a solid product.
·  Documentation should be concurrent with development efforts and modules and milestones are completed

Staging phase:
·  Roll out beta version of software, receive feedback and address issues and defects not previously encountered.
·  Release planning assessment making sure that we are meeting our original goal(s).
·  Ultimate goal is to produce a Release To Market version that is solid and effective.
·  If applicable, limited deployment for testing and evaluation.
·  Complete and/or update any documentation, training materials, CBT, etc.
·  Test builds, deployment testing, installation testing and appropriate regression testing to ensure backward compatibility if this is an existing product.

Production phase:
·  Ensure process/business owner has been a part of all phases.
·  Sign off from Development
·  Sign off from Q.A.
·  Sign off from Management
·  Upon successful completion of all requirements we can release this product to our target audience.

If we can follow the above logic and rules we stand a better chance of success. And while nothing is ever guaranteed, we can certainly tip the scales in our favor by being diligent.

Until next time,

Code with patience