in

Telligenti

Serving up fresh ideas every day, Telligent style

Karthik Hariharan's Blog

May 2007 - Posts

  • Microsoft at a Crossroads

    Microsoft's developer story has recently diverged into a tale of two cities.  Martin Fowler and Sam Gentile both recently wrote about it.

    On one hand, you have the traditional Mort-focused camp, which focuses on creating drag-and-drop developer tools like GridViews, DataSources, and Typed DataSets.  For this group, the traditional ASP.NET WebForm model appears to be the quickest way to Rapid Application Development.  However, RAD technologies like these tend to break down when they are used on many large scale projects.  This is generally is due to the lack of testability and the inherent bad practices that many new ASP.NET developers pick up when using the tools out of the box.  Without some solid best practices guidance, many ASP.NET projects often fall into a black hole when they reach the testing stage. 

    On the other hand, there is a large community of software professionals that utilize Agile development, Open Source tools, and better developer practices while still focusing on the Microsoft platform for their projects.  These developers often balk at Microsoft's attempts to copy Open Source projects and many find Microsoft's whole attitude towards open source to be very frustrating.  There has recently been a lot of concern that this group is likely to migrate to the Next Big Thing (whatever that may be) and leave the platform behind all together.

    While there are groups within Redmond that attempt to educate developers around some best practices, they aren't promoted well by Microsoft.  Also they also tend to face some backlash from the larger developer community due to the shaky middle ground they meet between the two sides of the fence.

    I am currently focused on developing for the Microsoft platform, but I have no reservations about moving to another platform at some point in my career.  I've done it before and I can easily do it again.  My main reason for sticking with .NET has been the amazing friends and colleagues that I've met while working with the platform.  The community that has grown around the .NET platform has been it's biggest strong point for me thus far.  And I think that if the more prominent members of this community start moving to another platform, I will definitely take a look at that platform for myself.

  • Being understood versus understanding

    A friend pointed me to this great article from Business Week talking about Ford's new CEO, Alan Mullaly, and some of Mullaly's experiences in trying to change the culture within Ford.  I found one paragraph that correlated to some of my past experiences as a software developer:

    After a couple of hours on the firing line, Ford's engineers got defensive. Interrupting the testers, they started airing their side of the story in front of the new boss. Sensing that the meeting was deteriorating, Mulally says he handed each one a pad and pen. "You know what? Let's just listen and take notes," he said. The episode was a perfect illustration of what Mulally considers one of Ford's major problems: the tendency of employees to rationalize mistakes instead of fixing them. "We seek to be understood more than we seek to understand," he observes.

    Developers have all found themselves justifying certain design decisions in an effort to complete tasks and move on.  This is a natural part of the process of software development.  But if their focus changes from understanding their users to making their users accept their design, then their software quality tends to suffer.  It's a difficult balance to maintain.

    I find that following the last two points of the Agile Manifesto would go a long way towards maintaining this balance:

    Customer collaboration over contract negotiation

    Responding to change over following a plan

    What are your strategies for understanding rather than being understood?

  • Following the Telliterns

    Internships are often an exciting experience for students entering many fields.  They can be a great place to learn, network with peers, and develop lasting professional relationships that will be important when first starting a career.  They are also a great way to "test drive" a company that you may want to work for in the future.

    Software internships can be especially fun in the right environments as they generally keep you very busy and give Computer Science and Information Systems degree seekers some much needed real world experience.  Many past interns, myself included, have found that their internships really defined the first few years of their career.

    To that end, Telligent has created an excellent internship program speared-headed by Jason Alexander.  Jason has dubbed them the Telliterns and has focused them on improving the Reporting features of Community Server.  In addition, Jason has required them to blog daily about their progress, experiences in Telligent's environment, and whatever else they choose to write about.  I really liked the idea of having them blog instead of collecting weekly status reports or bulleted emails.

    Each of the Telliterns has a very different blogging style and I've enjoyed reading about their progress as well as all the fun they're having!  I highly recommend adding their feed to your RSS reader and checking them out.

  • Review of Dreaming In Code

    I generally don't do book reviews as part of my blog, but after finishing reading Scott Rosenberg's Dreaming In Code, I can't resist.  This book is excellent.

    I first heard about it from Joel Spolsky and I also heard great things about it from a few attendees at the recent Dallas Code Camp.  So I went over to my nearest bookstore and picked up a copy.  By the way, if you're looking for it in Barnes and Noble, it's in the Science section, not the Computer section. 

    Dreaming In Code chronicles the development cycle of the open source Personal Information Manager software known as Chandler.  The vast majority of the book covers the Chandler project as a case study and describes team dynamics and design decisions and how both affected the outcome of the project.  It was interesting to see how even an open-source project completely driven by experienced developers and technical people can still have the same pitfalls of scope creep, fuzzy requirements, and poor design choices.

    However, I found the best material in Dreaming in Code to be in the chapters where Rosenberg steps away from Chandler and provides insight on the software industry as a whole.  I wanted to post a couple of the more thought provoking excerpts from the book:

    From a panel of experts assembled at a conference on software engineering, here are some comments:

    "We build systems like the Wright brothers built airplanes -- build the whole thing, push it off a cliff, let it crash, and start over again."

    "The problems of scale would not be so frightening if we could at least place limits beforehand on the effort and cost required to complete a software task.....There is no theory which enables us to calculate limits on the size, performance or complexity of software.  There is, in many instances, no way to even specify in a logically tight way what the software product is supposed to do or how it is supposed to do it."

    "Some people opine that any software system that cannot be completed by some four or five people within a year can never be completed."

    These grim perspectives sound familiar, but I left out one detail: This wasn't a  recent conference.  Every word I have quoted and thousands more like them, can be found in the proceedings of a 1968 summit on software engineering -- the first event of its kind, organized by NATO as its member nations started into the eyes of what they had just begun to call "the Software Crisis."

    I found this section very thought provoking as it makes it seem like we have not definitively solved some of software development's biggest issues despite staring them in the face for almost 40 years.

    Despite some of the perceived negativity towards software in the book, Rosenberg says blogging is helping to change things:

    And yet something extraordinary happened to the software profession over the last decade: Programmers started writing personally, intently, and voluminously, pouring out their inspirations and frustrations, their insights and tips and fears and dreams, on Web sites and in blogs.  It is a process that began in the earliest days of the Internet, on mailing lists and in newsgroup postings.  But it has steadily accelerated and achieved critical mass only since the turn of the millennium and the bursting of the dot-com bubble when a lot of programmers found themselves with extra free time. Not all of this writing is consequential, and not all programmers read it.  Yet it is changing the field -- creating, if not a canon of great works of software, at least an informal literature around the day-to-day practice of programming...It is also an open forum in which they can continue to ponder, debate, and redefine the nature of the work they do.

    I highly recommend that you pick up a copy of Dreaming In Code today!

  • Hanselman's Twittering for Diabetes

     Team Hanselman

    Scott Hanselman, noted developer and blogger, recently twittered his blood sugar checks in order to raise awareness of Diabetes. The full transcript of his twitters is now available on his site and it is definitely worth the read to see what an active diabetic goes through on a daily basis.

    My paternal grandparents both have Type II Diabetes so I've had a mild glimpse of what diabetes care involves. But for a person with Type I Diabetes, like Scott, the monitoring and adjusting of blood sugar levels becomes much more frequent.  Scott's twittering certainly opened my eyes to the urgency of his cause and I certainly want to do my part to help!

    Donate to Team Hanselman today to help fight Diabetes! 

  • Ideal Software Management

    Tim Stall had a great post entitled "Why would someone work for your company?" where he outlined a number of things companies can do to be more attractive for top developer talent without breaking the budget.  I highly recommend reading the entire post, but one point in particular got me thinking about software management.

    Good developers have the intrinsic need to grow and learn...Any manager that stifles that for any reason will simply push their best developers away. Such excuses may include: "we don't have time", "that's not in the requirement", "just do it this way because I said so", "this approach worked 5 years ago", "your job is to support the business, not research technology", etc...

    As a developer, how many times have you heard those last few phrases? I certainly have heard them many times from several managers in all different industries.  Most software managers would prefer to take approaches which they have personally seen work rather than attempt anything new and unproven. 

    This view often seems short-sighted, as most seasoned developers know that every software project can have dramatically different requirements and technical environments.  A good software manager has to understand the capabilities of both the available personnel and the technical environment to determine the best approach to the business problem. 

    I have seen many projects fail because the management decided to build a solution based on a previously successful approach but used a different set of programmers and a completely different technical environment.  So by attempting to be less risky by using a tried and true approach, the project actually has created more inherent risk by forcing both developers and technology down a path to which it may not be suitable.

    It's my opinion that if software management is willing to re-evaluate their personnel and their technical environment before embarking on a new project, they should also be equally willing to try a new approach or methodology as well.

Powered by Community Server (Commercial Edition), by Telligent Systems