Blog article
See all stories »

Object reference not set to an instance of an object.

Comments: (7)

A Finextra member
A Finextra member 08 August, 2012, 15:33Be the first to give this comment the thumbs up 0 likes

4. Definitely.

A Finextra member
A Finextra member 08 August, 2012, 18:35Be the first to give this comment the thumbs up 0 likes

It always suprises me how many Senior managers just don't get it.  Agile definitely helps resolves some of these issues. I can't understand for the life of me how anyone can deliver using Waterfall now.

A Finextra member
A Finextra member 09 August, 2012, 05:36Be the first to give this comment the thumbs up 0 likes

Paul, your list might or might not be accurate but you somehow forgot 2 top reasons that by far define the IT/software industry:

1) Client CIO's first and foremost loyalty is usually to his/her own morgage and transportability of his skills.  When the project fails the original CIO is already likely being far far away.

2) Vendor upsells what s/he has, never downsells (is it a word?) what the client needs - explicitely or implicitely.

Exceptions do happen - according to the numerous stats as much as 4% of all large IT projects are on time and within the budget.  If the client is that lucky, he should visit Makao.

Excuses, excuses, excuses...

Sincerely

Being There.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 09 August, 2012, 19:23Be the first to give this comment the thumbs up 0 likes

Brilliant post!

This list is self-admittedly applicable only for custom development projects. Many software projects involve customization and implementation of standard products (e.g. SAP, FLEXCUBE, etc.). In case you're planning to write separately about what makes such projects hard, here's one item to kickstart your list:

Drastic difference in what is expected from the software before implementation starts versus what is accepted after implementation ends. To cite an extreme example, many companies embarking on an ERP project expect the software to change the fabric of their company before starting the implementation but are willing to settle for accurate invoicing after ending the implementation! 

A Finextra member
A Finextra member 13 August, 2012, 14:31Be the first to give this comment the thumbs up 0 likes

Paul, this is one excellent compilation of why building software is so different than building manufacturing projects. It is much harder to evaluate good code and determine whether software is 'successful' at it's goal, relative to whether a bridge or tunnel is successful at allowing the safe movement of traffic. Of course, the purpose of the software project, i.e. gaming software, versus operational software for a life-saving medical device, will also determine 'how good' the software needs to be. With the 'algorithmic trading' software nightmares of recent days that threaten to take down markets and established companies, the level of quality and reliability needs to be set early on relative to the purpose. Software cowboys need to grow up and take their projects as seriously as structural engineers do when building skyscrapers. Better Quality Assurance, Testing, and extensive Alpha and Beta cycles are needed gain that first hand feedback that end users cannot possibly provide until that point in the dev cycle.

Consumers need to value important software more as well. Right now, with respect given to your number 5, anyone can hang out a shingle saying they are a 'software' development house. But not anyone can provide an ERP system, or banking system of record, or algorithmic trading platform. There is great value in software that works.

Hopefully, as the industry matures, a more pervasive understanding of the challenges you list will drive better software builds.

Gregg Weintraub
Gregg Weintraub - State Street IMS - Princeton 13 August, 2012, 18:05Be the first to give this comment the thumbs up 0 likes

Paul,

Excellent post with many good points.  But at your premise you compare software to construction.  Another notable difference in this space is that the standards construction is based upon (units of measure, materials) are significantly more standard than the base units (operating systems, hardware platforms) for computing.  This is not just a function of youth, but certainly adds complexity to software development. 

I would be interested to hear your perspective on how much this factors into the issues above and what you think should be done to address this.

Gregg

Paul Smyth
Paul Smyth - Kynetix Technology Group - London 04 September, 2012, 16:28Be the first to give this comment the thumbs up 0 likes

To those who commented on my article - Many thanks for your feedback.

In a short article such as this I couldn't address all aspects of software development so all the comments just add further weight to this topic.

Yes it is primarily written from a custom development point of view and reflect 30 years of experience in this area. However, I've also been involved in many CRM and other packaged software implementations and despite the fact that they are supposed to be easier to implement because it's off-the-shelf software, I can safely say that that is not usually the case.

Regardless of the type of software, custom vs packaged, I see as much confusion in the minds of users about what they really want and expect as Ketharaman points out in his comment.

Brian's comments reflect many of my own beliefs. The term "Software Engineering" is used a lot. Mistakenly I believe. I don't think software is yet as disciplined a profession as engineering. As an industry there is still a long way to go before we can call ourselves real engineers.

Gregg is absolutely right in pointing out that the base units in software development are much less defined and stable as in construction. I immedately think of an analogy that building software on any platform is like building a skyscraper on quicksand.

 

Paul Smyth

Paul Smyth

CEO

Kynetix Technology Group

Member since

08 Aug 2012

Location

London

Blog posts

5

Comments

2

More from Paul

This post is from a series of posts in the group:

Business Knowledge for IT

This community aims to provide links, resources, book suggestions, tips and insights to facilitate learning and development of IT professionals in financial services, and to develop a forum for IT professionals to exchange views on various related items.


See all