Call it Lazy or Busy?

True to my twin headed quality - i cud not keep this blog running. You could call it Lazy or Busy or fizzed out. I am still interested to keep this updated. Hopefully will revist soon.

Busy!

Sorry I have been stuck on some busy schedule - both in my personal & work life... But who ever is following the set of articles, please come back in a few days for the next one... cia ta,

Infamous TCQ Triangle

Almost all project managers would be able to tell us about the TCQ triangle is... Time Quality & Cost. All good projects need to be delivered in the best of quality but with little cost & time?! How many projects would have followed that suit? - not many in Software world. This is the most important link as to why we need software methodologies! yes how in earth the project managers would know how much their project would cost and when the project will be delivered and how qualitative the product will be? Any programme head would want to be in the 'B' area from a time & cost perspective, but in C for quality (ref pic above). yes their wish is to spend appropriate time and cost but for the best quality.

This triangle has changed to a 5 factor traingle (Ref. below). This is a hybrid of the TQC but in different words!To address the key project management questions, people came up with estimation standards; to some PMs, it is second nature. Out of experience they can do it in minds! Anyway these are the factors that ideally any methodology should address i.e. the rudimentary stuff: If i use a methodology to develop software, could the method help me identify time, cost and quality elements?

Good old SSAD had a concept of function points; This method was firstly proposed by Albrecht and Gaffney. In this method , the size of a system can be computed by three components which are information processing size (Unadjusted Function Points-UFP) and Technical complexity adjustment factors and Function Points. But world has moved on...We are in OOAD world where UML has many different way of estimation. Use case points were first described by Gustav Karner. Then on its closely guarded by Rational Software A good article on use case based estimation could be viewed here.

The question that floats around: How many projects use one of the estimation processes? it need not be end-2-end academic, at least a basic estimation could be initiated with some science underneath... I have spoken to a lot of project managers, who always come back with a cynical answer... Then how one could expect the project to be successfully delivered?

Have you ever thought about Hardware components failing? How come you motherboard always functions correctly? How come the hardware underneath very rarely crashes and even if it does, its 99% because of the software malfunctioning? whats the TQC model for Chipset manufacturing? How do they always deliver to the 'T'. So why then Software Projects face a lot of failure? Can we not deliver at least 80% of a project in time, cost & good quality?

So how do the so-called agile software methods answer these issue? that's next week...

Software Development - A Background

During 1940's people started writing code for the early day computers and since then software programming has grown leaps and bounds. 1960's saw the evolution of compilers, collaborative tools based on Unix in 1970s and so on...

1980s was the period of step change when Bill & Steve introduced products such as 'Office' & 'Lisa' for home users or the personal computers that infused the drive towards software boom. The computer hardware and software developments were actually concentrated within the industry perimeter, 1980s slowly changed the model of operation. People have different views about the quality of MSFT products, but my personal view: MSFT and their PC based products was the key reason for the current day software prosperity. The moment industry based costly products became home-usable cheap commodities, the dependent by-products such as processors, software, memory etc started flourishing.

Billions around the world have started using softwares and the services that were offered to people via manual channels, slowly turned towards e-channel for delivery. Hence software business started booming!

We all know that this is a multi-billion industry and delivery of products needs to be well-timed, qualitative and cost-effective. Any buyer will buy a product with good quality and affordable price; from a competition point of view, it needs to be introduced at the right time.

'The secret of success is constancy to purpose.' - Benjamin Disraeli; Very true! In the case of software industry, the early software dev teams were forced to produce softwares to meet growing demands and many a times success was tough to hold. The products were either of low quality (e.g. MSFT) or high-priced (e.g. Apple) or not introduced at the right time.

I have to mention my wonderful days of my Masters degree, when we used to joke about the Pressman's Software Engineering book to substitute with pillows; these jokes ran rounds even after students joined software companies. That's partly an issue. Software beginners are not educated to understand some key challenges around their profession, seldom they realise how they constitute to a software building exercise.

Nut-Shell: Software development started out in a mad rush with less time for developers to think about nitty-gritties, quality, importance of modelling or the need to follow standards etc. To add, the IT-Services company were and are in a mad rush to use the opportunity to earn and spend less time to worry about some of the basic flaws.

Bottom-line - People began building the Software Industry upon a weakly laid foundation and it continues so... Developers, tech leads, architects (not all, certainly there are a good lot), indulged on geeky talks without knowing the whats and whys... I think this trend belongs more to the software industry compared to automotive or pharma or construction verticals. That's coz' people see softwares directly related to knowledge quotient of an individual and hence by the play of ego commit to glib.

(This isn't to offend anyone or finger point someone, but that's whats happening mostly; this series of articles intends to display some of those rudimentary issues.)

Next Article: The infamous Time, Cost, Quality triangle...

Prelude!

Why did we invent things and continue to automate a lot of things? Very simple - to have a easy life and enjoy life to max. Has this statement got anything to do with Agile development - yes!

Hardware & Software were one such inventions to make life simple and easy; but as a matter of fact those inventions have complicated life and all the software pros are fighting daily to sort it out. I have been in the software industry just over a decade and i am certainly not a master to question or bash anyone or anything; even if i became a master, i wouldn't want to. The intention of this blog is to highlight some of the common problems the software world faces today and how these so-called agile development is taking us into a fragile tomorrow.

When i started my life as a developer, i saw some unnecessary tasks as part of software development or to put it this way, the so called technical leads (except the first tech manager - he was the one who opened my think tank!) overlooked loads of things and that led to produce below-par software modules - so i said to myself ah, i will become a tech-lead and change this world!

Then i briefly took over leadership (yeah i actually had to lead myself many times - no body made me a lead and most software companies that was the case - at least from what i heard from my co-mates) and i realised that there are other things beyond my control such as ever-changing customer requirements, poor design, no future-proofing etc. These were beyond my reach. The technical architects were of a different view compared to mine(only one architect who saw the world in a diff angle that had similarities to mine - btw i am not a purist). - so i said to myself aha, i shall become an architect and change the world!

Then i became an architect. Now worthless business contracts and other business issues, pre-sales negotiations, etc etc came into conflicts and these were affecting the whole project heavily. - so i said to myself aha, what if i become a service delivery head who could negotiate contracts, sort out some of the key learning's i have had in my journey.

I have not jumped onto the next level, but that's around the corner.

In my next set of articles i would like to pose some fundamental questions and go through some of the key software models (jargons) and then discuss my views. These views are mine and do not reflect the view of either the current or ex-organisations. - Hello World! Feel free to challenge and that way it will be a mutual learning.

Next Article a Background to software development

A List of software developement models

"Hello World!"- an infamous quote for every beginner in software programming. Before I step onto discuss the agile software adventurous ways of crap programming, let me list the most used acronyms and jargons from the software world.

This is an incomplete list of approaches, styles, or philosophies in software development.

Agile software development
Agile Unified Process (AUP)
Open Unified Process
Cathedral and the Bazaar, Open source
Code and Fix
Constructionist design methodology (CDM)
Cowboy coding
Design-driven development (D3)
Don't repeat yourself (DRY) or Once and Only Once (O3)
Dynamic Systems Development Method (DSDM)
Extreme Programming (XP)
Hollywood Principle
Iterative and incremental development
KISS principle (Keep It Simple, Stupid)
MIT approach, see Worse is better
Quick-and-dirty
Rational Unified Process (RUP)
Scrum (management)
Software System Safety
Spiral model
Test-driven development (TDD)
Unified Process
Waterfall model
Worse is better (New Jersey style)
You Ain't Gonna Need It (YAGNI)

Why is this in light for discussion... wait until the next post...