BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Venkat Subramaniam on Facts and Fallacies of Everyday Software Development

Venkat Subramaniam on Facts and Fallacies of Everyday Software Development

Leia em Português

This item in japanese

Bookmarks

Software development is challenging and lot of fun, but there are several factors that interrupt the teams from succeeding in IT projects. These factors are usually not the tools or technologies but it is the people that affect the success of software development projects. Venkat Subramaniam talked about the facts and fallacies of everyday software development. He gave a keynote presentation at the recent CodeMash 2009 conference on what developers and project managers should watch out for to ensure the success of their projects.

Here are some of the fallacies in software development Venkat talked about in the keynote presentation:

More money and time will solve our problems:
Venkat said it's important to have clear "business objective" when working on the projects. He showed the statistics that 64 percent of the features implemented in a project are rarely or never used and the longer the duration of a project, the lower the probability of that project being successful. Software developers need to develop what he called the "capable and relevant software".

It's gotta be good because it is from this large vendor:
He questioned if we really needed EJB which (in some cases) made the development complicated and heavy-weight. The developers are partly to be blamed for this situation (by using the EJB's for pretty much all use cases). One of the reasons for the adoption of EJB was that the competition (not the need) led the way. The need should determine technology, not technology determining the need and it's not a good evolution for standardization to occur before innovation. Frameworks like Rails and Spring have shown us that innovation before standardization does lead to useful and relevant development frameworks driven by the community rather than the vendors.

We're off-shoring because it will save us money:
Venkat talked about the current off-shoring model and if it's really working or not. He compared the model when companies did everything here in US and we still didn't succeed. So he asked, why would you put oceans between designers and programmers and expect different results? Off-shoring model has mainly become a "Fail-for-Less" strategy. He suggested that project managers hire smart skilled developers, those who can learn fast and then give them the sharpest tools, tools with high essence and low ceremony. A small team of highly capable developers is better than large team of below average developers. He asserted that off-shoring is here to stay so we should take the advantage of real talent worldwide.

Dynamic Languages are not safe:
He talked about Java being strongly typed and you can still get ClassCastException if you are not careful when coding in Java, so are Ruby and Groovy languages. Strong tying by itself doesn't improve the code. Compiler is useful, but is often overrated because no compiler can absolutely verify the programmer's intent. He also recommended the developers to take the advantage of new dynamic languages.

Static typing is essential for code clarity:
Venkat said with discipline, the developers can write readable, understandable, and maintainable code in any language. He suggested the following practices to keep the code clean and maintainable.

  • Make method/class names descriptive.
  • Write short classes/short methods.
  • Let the team interact and communicate.
  • Write automated unit tests. Unit tests has redundancies of expectation. It forces you to design right.

He also discussed the importance of unit testing in software development life cycle. Unit testing is the software equivalent of exercising and that's even if it's so good, more programmers don't really use it. It helps improve the health of the code and if code is testable, its design is good. Venkat concluded the presentation stressing that it's important to express the "intent" in the software.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Software Development is all about the people

    by Hitesh Bagchi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great points!
    Unfortunate that we still keep ignoring these. Software development is completely people driven and people dependent. In spite of all the myriads of processes and methodologies the right human resources still continues to be the single most important factor to software project success. More than thirty years ago Dr. Brooks has mentioned about the best programmers as "10 times more productive" as the worst programmers. Over the years the divide is still pretty apparent. Yet we keep proposing "factory model" and other such so-called "high" productivity development methodologies!

  • Dynamic Languages are not safe:

    by Pete Kirkham,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > He talked about Java being strongly typed and you can still get ClassCastException if you are not careful when coding in Java

    Java is statically typed but not strongly typed; if it were strongly typed (like languages such as ML or Haskell are) you wouldn't get ClassCastException or NullPointerException.

    > He also recommended the developers to take advantage of new dynamic languages like Scala.

    Scala is statically typed, not dynamic. It has stronger typing than Java, which is one of its main selling points. Recommending it in a discussion about typing contradicts 'Strong tying by itself doesn't improve the code.'

    (I don't know whether the misunderstandings are yours or Subramaniam's)

  • Re: Dynamic Languages are not safe:

    by Srini Penchikala,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Pete, It was my bad on the Scala reference, I updated the post to remove the reference. Regarding strongly-typed languages, here are some links:

    Strongly-typed programming language
    Java Overview

    "Using a static, strongly typed language like Java puts the strongest possible constraint on the type of object at declaration time" (Scripting on the Java platform).

  • Re: Dynamic Languages are not safe:

    by Stefan Tilkov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "Using a static, strongly typed language like Java puts the strongest possible constraint on the type of object at declaration time"


    I'm very sure e.g. the Haskell and ML folks would strongy disagree with this statement :-)

  • Re: Dynamic Languages are not safe:

    by Sadek Drobi,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Java is statically typed but not strongly typed; if it were strongly typed (like languages such as ML or Haskell are) you wouldn't get ClassCastException or NullPointerException.

    Java is a strongly typed language. But it has a kind of dynamic typing represented in casts and reflection and that is where you get ClassCastException. So I would rather say it is strongly typed but not completely statically typed.

  • Re: Dynamic Languages are not safe:

    by Sadek Drobi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Pete please ignore my previous comment. I just agree with you.

  • Re: Dynamic Languages are not safe:

    by Sadek Drobi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm very sure e.g. the Haskell and ML folks would strongy disagree with this statement :-)

    True. Haskell and ML (F#, OCaml) compilers will try to put the least possible of constrains on your types!
    in f x =x , f will take type "a" which is anything...

  • Re: Dynamic Languages are not safe:

    by Pete Kirkham,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm aware the term has a variety of meaning, but that quote from the scripting article would just get laughed at by anyone with any exposure to strongly typed languages.

    The wikipedia article has the specific trait of strongly typed systems I was alluding to -
    "strong typing" include[s]: ... Disallowing any kind of type conversion. Values of one type cannot be converted to another type, explicitly or implicitly.

    A programming language where ClassCastException can exist is not strongly typed - or at least, not as strongly typed a language as it could be. Java certainly does not have the "strongest possible" type system.

    The presence of ClassCastException indicates one of the weaknesses in the Java type system. NullPointerException another (that any reference type can be substituted by an object of other type - null - at any point in the progrom).

    Rejecting strong typing because of weaknesses in Java is contradictory, like rejecting GUIs because of Windows 2.0.

  • Good points

    by Tony Ambrozie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    These are all good points that, despite being reminded of time and again, seem to fade away from people's memory exactly when they are needed the most.

    Throwing money and people at a project, especially when the project is already facing internal challenges is always a bad idea. Overall project size is almost invariably challenging good quality, effective management (at both individual and project level), good and well-managed requirements and expectations with customers and on-time delivery. Large amounts of funding lead to attempts to "boil the ocean" for features and/or capabilities not required, at least not immediately. The long duration implied by big-spend projects further dilutes the focus and momentum and "invites" attempts of scope-creep.

    Solutions from large vendors are not necessarily bad. Many times there are good (although maybe not always visible to all) reasons for going with them, even when heavy-weight. The art and science for architects and managers is to balance effectively the pro's and con's in each particular instance (and vis-a-vis the enterprise environment), removing extraneous considerations -- however well intended.

    As to off-shoring -- as in geographically dispersed teams and team members -- it is important not for the (perception of) cost reduction --disputed by some studies and diminishing over time anyway due to improving wages in "off-shore" countries -- but for the simple fact that good people and subject matter-experts are not always conveniently located in the same city or even country when they are needed. Our project management methodologies and frameworks must evolve to effectively harness these people's capabilities wherever they happen to be located.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT