My last post has ignited a lively debate, so I am going to continue the theme:

Starter: I think that the relative merits of compiled and uncompiled code come out about even. Mistakes that would have been picked up by a compiler are only picked up when the code is executed, making it difficult to debug. However, compiling can take a while, especially using a language like Java which doesn’t have separate header files.
Main Course: I don’t think that I have explained my problem with rapid prototyping properly. I don’t like waterfall/V model development as it presupposes that the requirements capture phase will be 100% right. Bollocks to that, it is the customers prerogative to change their mind on a minute by minute basis. This argument can also be applied to the design process whereby copious amounts of UML are produced before the first “{” has been typed. My weapon of choice would indeed be rapid prototyping and I am in favour of the prototype becoming the finished product. My point is that this process still needs to include a formal design stage, feedback needs to be sought from the end user after each iterative step and the timescales need to be realistic. Skipping or skimming over the design stage is likely to lead to an incorrect design which, due to the time constraints, will have to be bodged to get it to meet the requirements. Likewise, spitting out prototypes without getting proper feedback is likely to lead to wasted effort and bodging, i.e. if the end user decides that the code needs to be changed at step D and the development team has already spit out steps E, F, G and H, either the subsequent steps must be ditched, or bodged to fit with the new requirements. Some will argue that the commercial realities of business mean that you cannot follow the process that I have outlined, my answer to them is that I think that the commercial realties mean that you must follow this process. If you quote unfeasible timescales to your customer, you will only succeed in doing one of two things:
  1. You squeeze each step of the process to meet the deadlines and produce bug ridden code which is impossible to maintain. The code is then bodged repeatedly thus further exacerbating the issue.
  2. You afford each step the time it requires and completely miss your target.

The result is the same in both cases – you piss off your customer. Great business model buddy!

The subsequent debate will centre on getting the customers in in the first place, i.e. if you quote twice as many man hours as the next guy you are unlikely to secure the contract. This is true, but how long will you stay in business if you match the quote of the next guy? I would not expect a new company to make a profit immediately, initially, I would expect the company to focus on building a reputation such that customers come to understand that it produces quality code, on time and on budget. I know this is slightly utopian, but it worked for my Dad and his company!
Desert: Documentation can be useful! I am absolutely against producing reams of box-ticking documentation. If it doesn’t help the development then don’t do it (the proviso to this would be where the documentation is officially required, i.e. to fulfill ISO-9001 obligations). Wherever documentation is completed it should be done properly, i.e. not after the fact to appease the box tickers!
What do you think?

3 thoughts on “++C++

  1. Starter: There is also tends to be more of an overhead with compiled languages: extra syntax to please the compiler; restrictions on what you can write because it has been decided that the compiler should be able to check everything up-front.

    Main Course: I agree with what you are saying. I think software development is a business where the customer isn’t always right. They may not realise the consequences of their demands on the development cost/timescale. Each of their requirements should be forced work work quite hard for inclusion in the final system. All comes back to my point about trying to write less code. Probably better to deliver a system that does the core 80% functionality superbly than attempting full functionality, where the last 20% of rarely used functions takes a disproportionate amount of time to implement.

    Convincing customers that 80% is what they want would often put a strain on the relationship between software development supplier and customer and the politics involved should not be left solely to the software engineers.

    Getting customers. This is quite alien to me, coming from the technical end of things. I would find it more comfortable to develop services/products that I think people would want (obviously with research to back it up), then try and sell them.

    Dessert: Documentation can be useful, I agree. Shame that most of what is produced isn’t. Despite working extensively with various quality procedures and standards, it’s only real benefit appears to be to satisfy customer’s qualification requirements. And this is despite really trying to make it work properly at least once. I regret the enormous cost and effort that goes into quality systems that do so little to actually improve the quality of the end product: the software.

  2. I think you have highlighted my number one good software requirement – the strength to know that your customer is not always right, and the strength to be able to tell them.

    Bend over backwards for your customer, don’t just bend over!

Leave a Reply

Your email address will not be published. Required fields are marked *