I have picked up many lessons along the way: on things that work and things that don't in software development, in running a business, and in developing an IT strategy and plan. My goal for writing this blog is to help others avoid the mistakes I made, and to start the dialogue on how to change the IT landscape. I want us to look at the way we do things and ask ourselves how we could make them better.
Much has changed in the field of IT and its customers. In the early days, IT resembled more of a religion. Practitioners -- analysts, programmers, and system administrators -- were the only ones who knew the truth. Mere mortals (aka the users) had to grovel and please the gods in order to get assistance. And if users were not worthy enough, they deserved wrath and punishment.
Here's one hint about the old world order in IT. When the internet began to boom in the mid-1990s, system administrators traded anecdotes about stupid customers, like the ones who forgot to turn the power switch on, or the ones who didn't have a modem but still tried to dialup. I am guilty of trading those stories too, since I personally encountered them.
Today, in a very competitive market, customers have become more demanding. They have more power. Because there is more competition, customers could switch to the competition more easily. In the Philippines, Manila developers compete not only with Indian developers, for example, but also with developers in the provinces.
Non-IT businesses have realized that in this arena, what will set them apart is to offer better customer service and better products. IT businesses, however, are only belatedly and begrudgingly acknowledging this new competitive environment. The result is that we still run in an environment and create products that are:
- Not user-centric.
- Averse to communicating and building a relationship with customers.
- Inflexible to change.
- Promise too much but unable to meet actual requirements.
- Often delayed and costly.
For a period of time, I thought that only I felt the same way about my field. And then I read about the interview of ArsDigita founder Philip Greenspun (Founders at Work), who also complained about the arrogance and lack of customer-focus among software developers. Greenspun asserted that real engineers (ie, civil and electrical) talked to their clients and involved them to create solutions that solved the real problems of the customers. That's a far cry from what's happening to the IT industry today.
Creating change in the IT industry will take a lot of work and a lot of re-examination of ourselves, our attitudes, and our behavior. I believe we can do it, partly because I've worked with and met many IT people whose mindset and behavior prove that there is hope.
Inflexibility, and delays are, in my own experience, at least partly down to not paying attention to code quality: It's harder to maintain and extend code that's written poorly. The very first large project I dug into was like that - for the people who followed me! A couple of years after I left that project, I learned that the subsequent team basically wrote a new application, discarding two years of illegible code. That was a humbling experience. The lesson's been driven home by working with three subsequent employers, maintaining legacy code, and you can be sure that refactoring (rewriting for legibility or to optimize performance) is bloody business.
ReplyDeleteSeveral years into a programmer career, I still don't know what magic combination of skills, attitudes, and tooling will deliver high quality code in my domain of Web application design when wielding teams. It's a slow climb up the learning slope, one project at a time.
Thanks for your comment and candor, Toff. It will take a lot to make the change that I'm talking about. We cannot do it on our own -- it has to be a collective and multidisciplinary effort. More about this as I continue the blog. :)
ReplyDeleteIt was a nice read. I sincerely believe that as Software Practitioners, we encounter
ReplyDeletesuch occasions where we just do our part from a 'myopic' stand point but the overall
philosophy of the requirement has not been understood or analyzed. I find many teammates complaining over the significant 'gaps' from a functional standpoint, thus leading to an implementation that is not user-centric. However, on the flip-side, sometimes these gaps are there to give you an opportunity to call the shots and do it your way (even if its just a bit).
I found an interesting analogy on the web somewhere where the author equated software engineers with 'gardeners'. You probably have a good idea of what your garden should look like a week into the future. You might even have a rough idea of the shape you expect it to be in a year from now. But you have no idea of where each branch, leaf, stem and flower will be a year from now, and if you say you do then you’re really only guessing. If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believe you.