Project Management

Developer Book Syndrome

Ben Kloosterman — Sun, 01 Nov 2009 13:33:07 GMT

A colleague of mine once stated that creativity is rare in technical people I had my doubts at the time as I’m fairly creative and often build unorthodox solutions tailor made to the problem but the longer I’m in the industry the more I agree.

The biggest symptom of this is something I called book syndrome. This is where famous author xyz ( eg Lowly , Fowler etc etc ) writes a strategy in a book and people use it in completely in inappropriate circumstances. When challenged on the solution they use the authority of the author to emphasize they are doing the right thing. While this technique may provide some job protection it is questionable that the famous author intended to apply it where it was applied ( eg Juval Lowly SOA 1 service per class ) and in many cases like Fowler there are many methods yet a single patterns is repeated ad nauseum without any concern for the special cases for each project..

And it is not just books, Universities have a lot to answer for drumming in OO yet for a lot of small to medium projects scripts and RAD provide better and more consistent results ( OO /RAD is Software theory relevant) . The fact is the bedrock of nearly all programming theory is based on 90% of the cost of an application being maintenance while true in the 50-80s this is clearly not true in the huge amount of small applications and scripts that never enter software studies ; in fact most of these programs never change over the life time of the program ( and are completely rewritten in a new technology after 10-15 years) is completely at odds with most of software development theory. I’m not against OO but I am against using OO in many inappropriate situations ( eg blindly following book – book syndrome) – even in an OO house RAD development will be faster , cheaper and deliver more reliable project deliveries.

The whole concept of an OO development house , an SOA house or a RAD house seems very wrong . Each has their pros and cons for each project and any competent team should be familiar with all techniques and use them where appropriate.

Every project needs to be taken on its own merits and facts like these are FAR more important whether OO is better than RAD or SOA.
- Amount of change /maintenance over the life of the project
- Fixed price contract
- Team skills (Architecting for the team)
- Breaking down the work ( eg SOA service layer and RAD front ends)

Is software theory relevant

Ben Kloosterman — Sun, 05 Apr 2009 08:12:57 GMT

I just realized my main objection to heavy theoretical based development stems not from poor theory but in appropriate use.

I think it comes down to the original premise that 90% of a softwares lifetime budget is in maintenance . While this is certainly true for large scale mainframe applications or software vender apps ( eg IE , Word etc) it is not for the majority of small apps used today. I have seen many of these applications not change for 90% of their lifetime and when replaced they are replaced by the latest and greatest language /technology.

Here is the thing i object to most - Using code that is very heavy in terms of re-use and extendability but is difficult to read , understand and overly complex. You can add to this the issue of developer skill level. Now if i have a team of 10 skilled developers building a 2 year system , its certainly going to be a major system that will last with a budget probably in the 1-4M range . However for the more common typical smaller app with 1-3 people for 1-3 months it is important to follow KISS and keep the initial cost as low as possible.

Considering this scenario makes up the vast amount of development projects ( and most programmers work) its surprising it is neglected by academia , there seems to be very little advice in building small systems as cheap as possible -

Commericial vendors have always embraced this market with VB , FoxPro , Clarion all the 4 GL ( Progress etc) but it seems sadly lacking in Universities and academia mainly because its not that interesting. Instead of that make a graphic rendered in your Comp science course a better project maybe complete a simple 3 form and DB app with some master detail screens , you have 24 hours.. At least they would be more prepared for most workplaces.

The slowness of modern development has also caused frustrations between IT and business specifically business will want an application to try a business venture however after they jump all the hoops and standards the whole startup is likely to not be viable. I have heard many business people talking about a quick win , while ther are many examples i clearly remember a business person being talked into an expensive product , like an Adobe Sharepoint type app where , the business could code business forms in Javascript and they would use the skills of the vendor for the first few form , laughable but you can see they want the quick win. While i knew nothing about the product I knew the organisation had no HTML or Javascript skills and know it will probably end in grief. The lesson here is we need to provide a quick and dirty option for the business more often .

POS or SOA Lite TODO

Ben Kloosterman — Mon, 09 Feb 2009 05:34:40 GMT

I think Service Orientation has gone the way of J2EE/ EJB and needs to be pulled back like was done with POJO.

I propose POS Plain old Services or POSA for Plain old services architecture.

Rules.
1) There is only one rule and that is KISS.

Agility vs Planning

Ben Kloosterman — Thu, 05 Feb 2009 03:54:21 GMT

Pretty nice discussion about the book Balancing Agility and Discipline
http://www.reliablesoftware.com/DasBlog/default,month,2007-05.aspx

Im think if you have too much agility you will not get a very good ROI from your investment ( though everybody maybe happy except for the person who pays the bills)

Are projects getting more successful

Ben Kloosterman — Thu, 15 Jan 2009 16:11:40 GMT

Im curious at the increase rate of sucess in a number of surveys such as the later CHAOS surveys. Looking in the detail however it appears that projects after peaking in 2000 the amount of time overrun and the amount of features completed have dropped dramatically in the vast majority of projects. Not sure what it means but to me it DOESNT mean software development is getting better if features are getting dropped and there are increasing time blow outs.

Things that come to mind

Standards for success and projects have increasing amounts of over estimation to prevent failure and hence they come on time and on budget. (See should projects have risk contingencies)
Core elements which are critical to the business with good ROI are being prioritized and delivered while less critical features are not.
Less framework creation /coding is resulting in higher success. ( Projects with poor framework progress are/were often cancelled early as they had few deliverables)
How can the time blow out and the project still be considered a success
Projects are smaller. A lot less managers have the stomach for the $100M+ projects in the 90s

It also very interesting surveys with a loose success definition have a much higher rate

http://www.ambysoft.com/surveys/success2007.html

shows success rates as 63-72% vs 34% for Chaos . I think you MUST have a concrete definition to get anything from a survey in terms of project management and Development methodologies otherwise it is too subjective based on the team .

Chaos defines success as “on time, on budget, meeting the spec”,

With looser definitions of success you get some interesting things

"40.9% of respondents considered cancelling a troubled project to be a success. "
The offshore rate of 43% shows how subjective a non standard definition can be ( People will rate external teams harsher than teams they are part off) . I have yet to meet a company that allows offshore firms Agile methods. People often ask these firms fixed price - which no doubt affects quality and perception but the ultimate goal of ROI is likely to be better ( IMHO).

Yet project success and budgets in Agile environments are hard to relate back to the requirements and original plan.

My feeling is projects are getting a bit more succesfull however i also think the cost of new software has gone up massively. This is good in that business are willing to pay it but bad in terms of ultimate benefit and ROI . Part of this is due to higher demands from business while in the past internal applications had a simple grey form now people demand colours , fonts a web interface for access at home , animated indicators etc

Its worth stating the massive improvements in the tools ( where did the time go) . I'm definetly become a believer in Parkinsons law which has pretty big implications for software development

Work expands so as to fill the time available for its completion.

In its generalized form.

The demand upon a resource tends to expand to match the supply of the resource.

In software its more likely that the work expands to fill the time available +0-50% depending on how strong the management is .

Looking further i found this

http://www.focusedperformance.com/articles/ccpm.html pretty spot on in describing the problem.

An aggressive target duration schedule, along with elimination of task due-dates, minimizes impact of
"Parkinson's Law."

Anyway the thoughts are a bit loose in this post .

Architecting for the team

Ben Kloosterman — Sun, 11 Jan 2009 12:39:18 GMT

One of the major differences between the oft and bad used example of building Architecture and Software architecture is people. When you build a building people know how to pour the concrete and a few specialized roles are imported electricians etc but with software we are expected to know all. If you have been writing Windows Forms apps for years if the new project is a web app it is expected that you know write a web application , the only exception seems to be with languages people seem to except a C# programmer cant write VB or Java - which is amusing as IMHO its probably easier to change language than to change roll ( Web /Service/Forms or DBAccess/Logic/Gui or Procedural/OO) .

As architects this is our number 1 problem , we worry about SOA , EDA better OO designs etc but unless you have the people the results are poor.

While some organisations wisely train these skills on lesser interim projects, in the majority the major projects get the attention and big changes.

When you begin your design consider your teams skills before anything else. Its better to do an important project in old technology eg VB forms and Databases then blood a team on SOA/OO . You will meet your deadlines and have far less issues. If you have some people who are skilled its common to make your services OO/SOA/EDA and leave the client technology as tried and true.

This is especially an issue for SOA/EDA designers as you are caught in a catch 21 , you dont get the benefit unless you work with big/critical systems but you dont get the skills unless you start doing some smaller systems which will be over-engineered.