Contents tagged with architecture

  • Why I believe in lean software development

    171 comments

    Few weeks ago I got myself an Amazon Kindle to facilitate book reading and hopefully get back my reading habits. I am so amazed by the device that today I twitted “it’s my best gadget”. now there are very genuine reasons behind the twit.

    it’s meant to be used to read books and it does it perfectly.

    • it has a great screen which is optimized for the reading.
    • does not hurt your eyes.
    • you can read books even in the direct sunlight.
    • it’s handy and light so very easy to carry with you
    • it’s got a long lasting battery life
    • bot built in dictionary which is extremely easy to use
    • has got a great search functionality
    • has got wireless connection so that Amazon can push the books immediately to the device
    • it’s very very easy to use

    I have just mentioned couple of it’s great features. don’t get me wrong, I don’t work for Amazon and I am not doing any promotion for the Kindle. the moral of what I have mentioned above it that IT DOES WHAT IT IS SUPPOSED TO DO AT IT’S BEST.

    I mean when I need a device to read books on it, I don’t need to have a million color screen with back light which would hurt my eyes and make them tired after couple of pages. yap I agree it would be good to be able to play 3d games on it BUT it requires changing the display type or maybe putting two different displays in the device –crazy but possible-. I would call either of them over engineering which will work against the device objectives. the same scenario is true with almost all characteristics of the Kindle.

    now the reason I believe that software development and management should be done in the same way that Kindle development is done is:

    • before starting a new software project, the team should be clear about what they are going to do. i.e. they should know they going to create a book reading device or a gaming device
    • they need to focus on what they are supposed to deliver and how they can deliver it with the best quality. i.e. they need to focus on delivering a device on which reading the book is easy and it’s not important if you can play games on it.
    • they should keep the life as simple as possible not try to inject extra functionalities to the deliverables until and unless it’s absolutely required. i.e. I don’t need to have joy stick on the Kindle I’d rather have to buttons to navigate through the pages.
    • stop over engineering the project. gold plating and over engineering the deliverables most of the time will distract you from focusing on the core values of the project and very often will be your own headache cause you don’t know the impact it. i.e. Kindle does not come as a dual screen device on which you can watch movies and read books because this is not Kindle’s objective.
    • keep your solutions easy to use
    • and finally never give up improving the quality of the functionalities you provide

    so these were some of my ideas on delivering software systems the same way Kindle was delivered. I strongly believe most of the software systems development fail either because of the ambiguity of the deliverables specifications or because of over engineering the solution.

    Written by vahid

    Wednesday, March 7, 2012 at 4:52 AM

    Tagged with