It’s time to "mobilize"

I remember not so long ago businesses weren’t serious about selling products and services on the Internet. They thought that people wouldn’t actually buy products and services online. Well, those who believed so missed some excellent opportunities and allowed competitors to take a big chunk out of the market.

Here we are, in 2008 and a lot of companies aren’t so serious about selling products and services via mobile phones. Let’s fast forward to 2011. Every phone has built in full internet browser; at least 4 GB built in memory and accessing internet with 3G (or should I say 4G) speeds. Every online retailer offers services and products on mobile phones. LBS or Location Intelligence services provide timely custom information to consumers based on their location. And all of the above is taken for granted the same way as services and products offered on the Internet.

Do you want to be a company that “mobilized” in 2009 and improved their offerings every 6 months to be one of market leaders in the mobile space or a company that realized missed opportunity and started their “mobilizing” efforts in 2011?

What to do when client asks for quick-and-dirty solution?

I made a presentation and a proposal to one of my clients the other day to develop a customized ERP solution for their unique online auction system. This was a 7 page document which included research and comparison of 3 open source ERP products, architecture diagrams and a detailed project plan.

They liked all of it except the total duration of the project, which was 3 months. I was asked if I could do a less than perfect job and deliver a “quick-and-dirty” solution, because their business needs something quickly.

I politely refused.

I could’ve just said “yes, I can do quick-and-dirty”, make quick buck and go on to service other clients. Sounds good right? Wrong! If you’re a consultant or contractor, your reputation depends on quality of your work and on what your former clients say about you.

Say you develop a quick-and-dirty solution. It works for your client for a few weeks and then suddenly it breaks because 10 users tried to use the system at the same time. Who do you think the client is going to scream at and blame? Right, you. Do you think they’ll refer clients to you or say kind words about you and your services?

When it comes to providing services, quality should be of utmost importance to us as consultants. At the end of the day our reputation is more important than a few extra bucks in our pocket.

How many years of hands-on experience is enough?

I recently stumbled upon a question on linkedin.com regarding developers in India with over 10 years of experience. The question originator said that there is no such thing because anyone with over 10 years of experience has moved on from development to management or architecture. Another person said that anything over 5 years of development experience is just gravy.

I agree with the question originator, but completely disagree with the second person.

I personally have 18 years of hands-on experience. Over the course of 18 years I went from IBM midrange environments to Microsoft Client/Server to Unix/Linux Java based platforms. I held positions ranging from programmer analysts to development manager to CTO but I managed to stay hands-on because I love technology and I don’t believe an IT Executive can be a great leader and mentor without a solid hands-on foundation and a good mix of up-to-date knowledge of technologies, especially as a consultant.

I’ve interviewed hundreds of developers and so-called developers and for the most part anyone with 5 to 10 years of experience makes a much better developer then one with 3 to 5. What’s important in software development is the basic foundational knowledge of software development. Knowledge and solid experience with object-oriented design, distributed applications, web-enabled solutions, and databases make a better developer then experience with latest tools and frameworks. Recent tools and frameworks simplify developer’s life by letting him/her concentrate on coding business logic. This is great, but it also opens up a lot of potential problems. A developer who uses frameworks without understanding how those frameworks actually work is like a race car driver trying to drive a race car without knowing what it means to shift gears and when to actually do it.

The only way to get experience and knowledge of the fundamental design and practical skills one has to spend a number of years actually doing it. Therefore a developer who is promoted to an architect or technical manager after 3 years in the field usually fails to deliver quality solutions. On the other hand, someone with 10 years of hands-on experience is usually both a great developer and a good fit for technical management jobs.

Agile and offshore teams

I had an interesting conversation a couple of days ago regarding Agile methodologies, Scrum in particular, and how it can be applied on my current large software development project. I am managing a team of 17 developers, architects, qa, web and database folks on this project in 3 different locations, including 7 developers in India. The person who suggested the use of Scrum based methodology for our next project phase is a very senior developer/architect on my team. I personally like the approach but I don't think it will work for this particular project. Scrum or agile in general assumes certain level of experience and responsibility on a part of developer. It also assumes that people work in smaller teams and normally in a single location. There is no reporting hierarchy as such within an Agile team.

It is common knowledge that when dealing with large outsourcing provider, the client normally gets junior developers (1 to 3 years of experience) to do the actual work. Lack of experience and inability to make important decisions makes it difficult to go agile all the way. In addition, there is at least 2 layers of offshore managers/coordinators/micro managers who watch over the offshore developers. Agile will not work with such structure.

The way I look at it, agile is like having a swat team of highly experienced professionals who can work well together to deliver frequent quality results. Anyone with over 5 years of experience at an offshore company will move to a more managerial position unless they become independent consultants. From what I've seen with large offshore firms, it is impossible to put a team of developers together where each developer has at least 5 years of hands-on experience.

My conclusion is I won't attempt full agile approach when dealing with offshore teams. I will and do use partial agile approach on most of my projects though. I wrote about this in one of my previous posts.

Software development project risks

I’ve seen project delayed on many occasions for many different reasons, but 3 of the following are the most common (assuming that the development team and management are good to start with).

• Schedule flaws due to inaccurate estimates.
• Scope creep due to additional requirements after the initial signoff by management.
• Resources turnover - people come and go.

Here is another risk that I encountered which is sometimes overlooked.

• Slow response from users

Here is a real project I did for one of my clients. I developed a complete web portal solution for a medium size business. It took my small team (myself, 1 developer, 1 web designer) a total of 4 months to complete the development. I scheduled 1 month for UAT (User Acceptance Testing) with the assumption that users will do extensive testing and send me a weekly report with issues/bugs so we can fix them ASAP. I was chasing users for 3 weeks and got nowhere. At the end of the so-called UAT period, only 10% of the functionality was tested by users. The developer who worked for me had certain commitments and was no longer able to work for me. I had to find another developer to help me finish the project. It took extra 6 weeks to find new developer, do UAT and fix the bugs.

So it is important to explain to the client that if she wants a timely delivery of a custom solution, it requires not only quality work on a consultant's part but also good communication and timely responses on client’s part.

Data Services – SOA for data

Most established businesses have more than one database. This is especially true for those that have different business systems for different activities within the company. So if a business has an Order Management, Inventory Control, CRM and Sales/Marketing systems, then they probably have at least that many databases. In most cases, there is a lot of redundant data in those databases and it is also not unusual to have data discrepancy from one database to another.

So, at some point, company management discovers that having redundant data and processes actually hurts the business – surprise!

An immediate reaction can be:

“Let’s create a single database and move all the redundant data over as well as change all the processes to point to the new database”.

-or-

“Let’s change all the data entry, validation, feeds, and other processes to use the same logic when storing data and then fix all the discrepancies so they don’t happen again”.

Above solutions were probably good alternatives 10 years ago, but they are wrong solutions today.

The best way to handle multiple systems and databases is by creating a Data Services Layer between all the system’s business logic and the databases. This is a stripped down version of SOA (Service Oriented Architecture) applied to data, which will allow preserving existing application and database investments and at the same time ensuring that all business data is being retrieved, validated and stored in a uniform manner via Data Services .

Data Services will also open door to improving business processes across the enterprise and allow quick turnarounds when developing or customizing business applications.

Agile or Not?

It’s been asked by many technology managers and developers if agile methodology is the way to go. There are plenty of technologists out there who say “yes” and plenty of others who say “no”.

I’ve been developing and managing custom solutions for over 18 years. There was no agile methodology when I started in this field. There was SDLC (Software Development Life Cycle), which required a very well defined approach of going from requirements to architecture/design to development to testing and finally production rollout. Projects took 6, 12 and 18 months before being rolled out to production. SDLC is still being used by most development teams today.

Agile is something completely different. I am not going to define in length what agile methodology is – there is plenty of websites and books on the subject. The gist of it is - working very closely with the users, developing and delivering small pieces of the application on a frequent, iterative basis, doing a lot of testing and continuously integrating the code.

Then, there is a third approach – the one I like and use for most of my projects. It’s a mix of SDLC and Agile. Working with many companies as a consultant, I realized that pure agile methodology will not work due to one simple reason – not having detailed requirements specified and approved by the user before starting the development will create many problems. So I believe in gathering detailed requirements before jumping into iterative development and frequent deliverables. That said, once the requirements are approved by the user, the design and development can actually be done using agile methodology. It is actually beneficial to develop various components and release them to production before the whole project is completed. This will provide users with certain level of comfort that things are getting done and it will provide development team with constant feedback from users. Problems discovered early in the process can be fixed much easier than those discovered after 6 months of development.

So, be pragmatic and combine the best practices and technologies. What is most important is delivering working solutions.