The Server-Side Pad

by Fabien Tiburce, Best practices and personal experiences with enterprise software

Archive for April 2009

10 Twitter Tips for Professionals

with 2 comments

I am an unlikely fan of Twitter, the rapidly growing “micro-blogging” platform (I won’t call it a site, read on…).  For starters, I don’t particularly enjoy gossip.  I have no interest in celebrities and I think Smalltalk is a computer language.  So like many, I hesitated to join Twitter.  I was afraid it would amount to pointless chatter, noise.  That was then.  This is now: in a matter of weeks, Twitter has not only become useful to me, it has become downright essential.  Here are 10 Twitter tips I hope professionals find useful.

1. Twitter is a bit like eavesdropping.  The conversation is as good as the participants.  Follow interesting people, creative thinkers, prominent speakers and chances are you are going to be enlighted by a constant flow of insightful tweets.  Follow “noise” and the pearls of wisdom will be few and far between.

2. Follow your friends and peers, sure.  But mostly, seek out people you wouldn’t normally get to converse with.   Unlike LinkedIn, you can virtually follow anyone.  This is unique.  Following someone on Twitter is a bit like being allowed in his or her inner, albeit public, circle.  Twitter has given me new perspectives from people I may not otherwise meet, listen to or learn from on a day to day basis.

3. Everything you say is public.  The search engine in Twitter is very good and real time. The appearance of “inner circle” privacy is just that, an appearance.  Be candid (most people are) but tweet accordingly.

4. Being a fairly public and open platform, Twitter is very transparent.  You can search Twitter (company name,  person, idea) using #hashtags.  This gives you a pretty good idea of  how the company or idea is being perceived.   Real time, unfiltered knowledge.  Brilliant for marketers, researchers and just about anyone involved in creating and selling a product or service.

5. Tele-presence.  There is a great conference in San Francisco you wish to attend but can’t due to prior commitments.  No worries.  Lookup the hashtag and “listen” for tweets on the conference.  Key points and take-aways will probably make it on Twitter before they show up anywhere else.  Not quite like being there, but close.

6. Twitter is a platform, more than a site.  The web interface is one of many ways to get on Twitter.  I installed a desktop client called TweetDeck and a BlackBerry client called TwitterBerry.  There are countless other clients which is further driving its adoption.  And there lies a valuable take-away on success 2.0: play nice with the community and the community will adopt you and make you successful.  

7. Twitter is not just about people, it’s about news.  I essentially stopped using RSS and now use Twitter to read updates from some favourite technical news sites such as Slashdot.  There again, Twitter is a platform more than an application.  Its potential is enormous.

8. Twitter can get your questions answered.  Sure LinkedIn has Q&A’s but the answers take days or weeks to come.  Answers on LinkedIn tend to be longer and well thought-out (some anyways) but they still take time.  Chances are, unless you are writing a research paper, you need answers at the speed of business.  The answers you will get on Twitter are more like insights, facets to the complete answer.  Quick, opinionated, maybe a follow up link or two.   From there you can make your own opinion.

9. Twitter restricts you to 140 characters.  What good can you say in 140 characters?  A lot!  Twitter forces you be concise, synthetic, to the point.  As a writer, it’s a good exercise in concision. As a reader, it’s a great time saver that stimulates the mind.

10. Remember Laurence Fishburne as Morpheus in the Matrix “No one can tell you what The Matrix is, you simply have to experience it for yourself.”?  Well so is Twitter.  Because of its openness, its choice of interface and who you follow, Twitter is what you want it to be.  Try it and you just might like it.

Follow Fabien on Twitter at http://twitter.com/FabienTiburce

Advertisements

Written by Compliantia

April 26, 2009 at 9:04 pm

Custom Software, Executive Q & A

leave a comment »

This post aims to answer some of the questions we frequently get from executives on what we do, the business and process behind information technology in general and software in particular.  First a preamble.  I don’t expect an executive to understand the intricacies and details of what we do as software engineers and consultants.  My job is to understand what an executive requires, what “pain points” might exist in the operation of the business, what opportunities might lie ahead and to devise and implement solutions through information technology.  My  job is to understand and communicate the nature of the solution, scope it, price it, build it and integrate it.  Our primary expertise is software, more specifically custom software.

What is custom software?

You can buy “off-the-shelf” software.  Software of this type is often, quite literally, available on a shelf at a computer or electronics store. Other times it is downloaded or procured from a commercial or open source vendor.  Most people are familiar with this type of  software because of the ubiquitous availability of some well known off-the-shelf software.  If you have used Microsoft Office, you have used off-the-shelf software.  Custom software is purpose built, or rather purpose “assembled” from readily available and custom-built libraries.  You don’t buy or download it ready-made.  

Is custom software built from scratch?  

Not at all.  Today’s application development is more accurately described as application “assembly”.  Architects and developers combine readily available libraries and components to meet the business and functional requirements of the system and the needs of the organization.  The widespread availability of these (often open-source) components has created a new breed of software development, one that relies on rapid prototyping and frequent iterations.  Good developers don’t reinvent the wheel.  They use tried and true readily available components, libraries and best practices.  They don’t make, they assemble.

Why do I need custom software, can’t I customize off-the-shelf software?  

It does depend on the software but in the vast majority of cases, you can, to some degree.  Appearances can be deceiving however.  Making changes to a large one-size-fits-all software application or platform can often be more expensive than purposefully assembling an application from loose components. The economics of “buy vs build” hinge on the nature of the application.  This is why neither should be a foregone conclusion.  Always start with your business and functional requirements, initially ignoring what you think is doable, perceived costs and complexity.    

Brand “X” off-the-shelf software does 80% of what I need.  How expensive will it be to build the remaining 20%?  

As I said above,  I can’t quite answer this question for each and every situation without further analysis.  But I can say this with absolute certainty: a lot longer than you could ever imagine and often a lot longer than the vendor is willing to admit.  Nowhere does the 80/20 rule apply more so than in systems.   You will meet 80% of your requirements in 20% of the time and budget.  Commercial vendors know this and are quick to sell you those features that come to mind.  Don’t assume what you didn’t see is easy to get; it isn’t.  The remainder will be expensive and difficult because by design, off-the-shelf software is meant to fit most organizations’ needs, not yours specifically.  Custom built software has a more predictable and linear complexity curve.  While not all features are equal in complexity and scope, building custom software has few or no limitations.  Any experienced professional can accurately scope and estimate the time and costs involved in building the features needed.

How do I kick-start a software project?

Every software project needs a mandate.  Software exists to serve a business and functional purpose.  Elliciting requirements is a job fit for professionals.  Any good software consulting organization will put forth experienced individuals in this area.  They will meet your stakeholders, will interview current and future users, will seek to understand the current business and functional processes the new piece of software is meant to support, alleviate or replace.  From this process, a list of mandatory business and functional requirements emerge.  Be specific and get everything in writing.  Upon delivery, the software will be passed by user acceptance.  User acceptance ensures that the system meets all requirements stated and is fit for deployment.  

How do I measure success on a software project?

Sofware should be easy to use.  What goes into usability is open for debate but the outcome isn’t.  Are your users productive?  Do they (the people actually using the software, be it your employees or clients) find it easy to use?  Have previously difficult and time consuming tasks become easier and faster?  Is the software intuitive?  Does it lend itself to experienced users and novices alike (a difficult balance by the way)?.  Usability is important.  Make sure you work with people who read, think and speak usability.  There are other facets, but this one cannot be overlooked.

Software needs to be fast.  Give the most patient person in the world a web browser and make him wait 4 seconds and you have a frustrated irate user.  Rightly so.  Software needs to be fast.  People are used to thinking fast.  Customers demand highly responsive interactions or they move on.  Fast requires proper software engineering and infrastructure.  Don’t assume any piece of software can scale.  That is simply not true.  Principles of scalability must be embedded in the application itself.   We listen to every word Google, You Tube and Facebook software engineers have to say because scalability is very much a science that relies on software patterns, design and infrastructure decisions.  You may not be as large as Google but scaling down is easier than scaling up.   In this regards, there is absolutely no substitute for experience.  Don’t hire an organization that hasn’t built something comparable in size or scope.  They will learn on the job, they won’t meet your expectations and you will miss your target.  Software engineers are worth every penny you pay them.  Expensive?  Just adopt the agile methodology and ensure most of your dollars are going towards the end product not superfluous management (not that management is superfluous but in agile development, extra process can in fact be detrimental). 

Software must be easy to change.  If I had to pick one symptom of poorly engineered software I would say, without a doubt, a pattern of “I asked how long it would take to make small change X and they said it would be Y weeks”.  The truth is not all software is created equal.  Good software is what we call “declarative”.  It can be changed easily because only key functions are “hard” coded, the interactions between code modules and functions to actually create processes are “soft” coded, typically in XML or configuration files.  If your vendor consistently tells you it will take days and weeks to do simple things, they may in fact be honest but (regrettably) incompetent.  Talk to a vendor’s existing or previous clients.  Was the software written on time?  Did it perform?  Were changes easily accommodated?  If any of these answers is negative, move on.  

Can my IT department write software?

Some can.  However most IT departments are usually barely keeping up with the ongoing needs of the business.   Freeing up resources to write and integrate complex software is often prohibitive.  Another angle is while some IT departments have in house talent able to write software, writing enterprise software is complex and very much a profession in itself.  Technical skills and development methodologies are taxing and time consuming to learn and master.  A little knowledge can indeed be a dangerous thing.  If a system is mission critical and/or will affect your bottom line, leave it to people who do nothing but software development.

How do I choose a vendor?

In operational and logistical areas, the size of the vendor is often proportional to the size of the project.  Software is  different however.   Software scales, not according to the number of people on the team but according to the experience of the engineers who architected it.  I once worked for a large consulting organization.  The pitch to your new clients was often the same: at the first meeting, they’d bring out the “stars”, the experts.  The client was wowed.  Clearly this is money well spent they felt.  Unfortunately, the contract would be signed, the stars would disappear, never to be seen again, and the client would be stuck with a team of recently hired “B” developers.  Projects at these large consulting houses go notoriously wrong and over budget.  Not to say that there isn’t a place for them.  But when working with software, get to know who you are working with.  And keep in mind that small teams do great things.  

What vendor would you recommend?

I thought you’d never ask!  We at Betterdot Systems practice what we preach.  We’re a small company of ultra-motivated highly-experienced software professionals who do great things.  Speaking with us is not cheap.  It’s free.  We want to understand your business and your needs before commitments are made or sought.  There are other vendors out there.  In fact if we feel that your requirements don’t fit our expertise and skill set, we’ll happily recommend a few.  Speak with your peers and ask them about their experience with software vendors.  And as I mentioned above, ask to speak with a vendor’s clients.  A good vendor has happy clients.  Happy clients are willing to talk.

25 Years Online. Do I Get a Balloon?

leave a comment »

MinitelI was 12 years old in 1984 when my parents brought home a Minitel.  It didn’t cost them anything.  The state-owned phone company (PTT who later became France Télécom) figured it costs 100 francs to print a phone book per year and 500 francs to manufacture a Minitel.  Hoping to recoup their investment in 5 years, they gave away 9 million terminals.  Phone books went the way of the dodo and a country, perhaps not realizing it, entered the electronic age.  France Télécom did a lot more than recoup their investment.  Private services flourished driving network fee revenues.  By the end of 1999, the network had 25 million users in France.  The Minitel is generally considered the world’s most successful pre-internet online service.  The network was secure (private phone company network) allowing online banking and electronic commerce to take off.  Booking train tickets, buying from electronic catalogues and looking up online databases were in widespread use by the late 80’s.  None of that really mattered to me at the time, I had discovered chat rooms and was hooked (did I mention the per minute network fees?).  The Minitel is a technological relic by today’s standards and yet won’t completely go away.  There are internet gateways for it now and it’s still commonly used for secure enterprise applications requiring a private network (which can easily be handled by TCP/IP technologies, virtual private networks, etc…).  Anyways, upon realizing I had been online for 25 years I proudly told my wife.  Now this may surprise you as it surprised me, but from the look on her face, I doubt I am getting a balloon…;)

Written by Compliantia

April 15, 2009 at 3:59 am

Success 2.0: Build Great Teams. Build Small Teams. Be Agile.

with 3 comments

colSuccess in the web 2.0 sphere makes for an easy sales pitch.  You need to spend less money.  You need to get a product out faster.   And the catch is…? None, but spending less is not as easy as it seems.    You need the right framework, the right partners, the right methodology.  Here are some principles Betterdot Systems abides by in everything we do…

1)  Build great teams.  As Marcus Daniels once told me, “You are better off starting a business with an A team and a B plan than a B team with an A plan”.   Why?   Because the A team will eventually gravitate to the A plan anyways.  The A team will innovate, will find the way, the shortest path.  Hire great people.  Work with great partners.  Build your A team.

2)  Build small teams.  Small teams do great things.  The mighty Google is said to have no team larger than seven.  Meanwhile Microsoft used armies of developers to produce the much vilified Vista operating system.    Build small teams.  Assign them a clear mandate.  Give them responsibilities.  Let them shine.

3)  Be agile.   Don’t fight change, embrace it.  Focus on the user experience.  Try rapid prototyping and commit to frequent releases.  Be nimble, be agile.

The principles above allow us to do more, do it faster and do it for less.  Sales pitches are so web 1.0… 😉

Written by Compliantia

April 13, 2009 at 1:37 pm

Nearshoring to Canada – Your Comments

with one comment

My blog post on The Case for Nearshoring to Canada seems to have hit a nerve, at least with unbiased Canadian readers  ;).  Unfortunately the article was cross-posted to LinkedIn so some interesting comments were posted there instead.   As a follow-up to the original article, here is a compilation of the most interesting comments, from various sources.  Thanks for your contribution.

Gary Toste writes: “For offshoring to be successful, you truly need to commit to it and integrate it into your processes and commit to going there regularly. So yes there are additional costs outside of just what you initially see to make it successful. As soon as you outsource anything, be it down the street, or half way around the world, there are complexities that need to be managed or things can fall apart. The further away though, the more issues that can happen. Timezone is by far the biggest factor in my opinion. ”

Sean Abel writes: “In my experience with offshoring (about 15 small to medium custom software projects with total combined budget of $1 million USD), the costs savings were negligible. In order to get the correct product on time with an acceptable level of quality, there is more time spent on the front end specifying (never a bad thing) and on the backend in quality assurance than is my experience with in-house talent. The one positive that I noticed was that the paper trail was more comprehensive than a typical in-house project. The biggest negative was the very few hours of in-office overlap between my North American assets and my overseas developers. This required resources on both ends to work some odd hours when resolving complicated issues. All in all I find that with my typical engagement I can deliver a superior product in less time for the same cost with a local development team. Manufacturing is an entirely different animal and not my core expertise.”

Marcio Ferrini writes: “…in Brazil the time zones, work ethics and business values are close as well. I think our main problem is related to instability of our currency. The exchanges rates vary so much every day and even we having contracts in dollars, we end up having expenses in Reais which has some time to be adjust.”

Peter Giblet writes: “In addition to your comments I would also say there are other advantages to leveraging Canadian skills in development projects. In addition to the reasons pointed out corporations engaging R&D resources do have significant tax advantages for new developments, provided the terms and conditions of an employees contract are correctly worded.”

Alex Boudarov writes: “There is no cost saving in outsourcing whatsoever. Indian devs cost between 20-60$/hr. Resources at lower price range overbill heavily, which brings the effective price point to North American standards. In my experience (I have seen how outsourcing in major financial institutions) it is more expensive then local development, especially considering lack of face to face communication, timezone difference and lack of control over the development process on their end.”

Steve Sykes writes: “When offshoring (and outsourcing, to a degree) got started as concepts, there tended to be a lack of a “total cost” view. Such a view would take into account all the great points made thus far here, and also things like vendor management – which requires visits to vendor facilities, etc. I’d like to see a “carbon impact” factor introduced to such analyses, as well as the productivity cost associated with an executive traveling to Russia, China or India. A week trip is usually stretched into 10 days or 2 weeks – and then there is the wind-down before the trip and wind-up afterwards. Whole lot easier (and less expensive) to manage a vendor in the same metro area (or at least, province). I would suggest that each such trip impairs between 1% and 5% of annual productivity. I’d also like to see all of the human costs sufficiently considered. “

Written by Compliantia

April 1, 2009 at 4:15 pm