|
The answer depends on the "mission-criticalness" of the project. MS can get by with still having bugs when the software is released. NASA, Boeing, or some place like that can not because someone's lives could depend on the successful execution of the code. They do not get to release "service packs" that make everything ok.
|
|
|
|
|
Couldn't a jet receive an update whilst in the air?
|
|
|
|
|
don't think so, it would probably need a restart :p
Clean Programming Under Difficult Circumstances
|
|
|
|
|
|
hmmmmmmm 
"Every rule in a world of bits and bytes can be bend or eventually be broken"
|
|
|
|
|
Marc Clifton wrote:
Writing less of it for more $$$
Absolutely. My overall aim in my life is to develop software without having to write one new line of code. We are still a million miles off that, but maybe one day.
Michael
CP Blog [^]
|
|
|
|
|
Bloody hell Butler, you sound like an advert for the next Visual Studio .NET... :P
I don't think the future is whether we write more or less code, it is the kind of code we write. I am fed up with having to write SqlConnection sqlconMain = new SqlConnection(ConnectionString); everytime rather than Get Customers With Debt from Main Database or some such.
Why are we still writing structs and namevaluepairs and pointers and byte arrays?
As an example; Right now I can use Dreamweaver to visually whip up XHTML compliant web-pages without writing a single line of code. They are as good as my hand coded ones, but I am quicker at hand-coding those pages than I am at dragging fiddly floating DIVs in Dreamweaver. Even with practice I won't drag right-floating DIVs faster than I can type div#News {float: right;}.
regards,
Paul Watson
Bluegrass
South Africa
Ian Darling wrote:
"and our loonies usually end up doing things like Monty Python."
Crikey! ain't life grand?
|
|
|
|
|
Paul Watson wrote:
Bloody hell Butler, you sound like an advert for the next Visual Studio .NET...
It was more of a subtle plug for the work Marc is doing with MyXaml... well that was my intention. 
Paul Watson wrote:
I don't think the future is whether we write more or less code, it is the kind of code we write. I am fed up with having to write SqlConnection sqlconMain = new SqlConnection(ConnectionString); everytime rather than Get Customers With Debt from Main Database or some such.
Actually, I'm fed up with having to write a customer database. I'd much rather be able to use the database that comes with Outlook or with Sage Accounts than having to build me own. Why is it so hard for use to be able to integrate with each others applications. Why isn't there a standard component that can be bought that provides the basic customer information that I can plug into my own app and just add my custom fields.
Why can't I easily hook the Make Call functionality of Outlook and redirect it to call my telephony code. Why can't I easily add a Dial button into the Sage Account screens and have it call my code.
Why should I have to write something that somebody else has already done, that my customer is already using but wants to make it do something just slightly different to fit in with their business methods.
We need to stop thinking of computer software as seperate applications and start writing software as platforms for others to build on. Hardware is component based, so why isn't the software built the same way. I want sofware plug and play.
Michael
CP Blog [^]
|
|
|
|
|
Completely agree, Michael. I just don't want people thinking the future is not to write a single line of code. When you use MyXAML you are writing lines of code, nice code but still code IMO. The way MS and others make "no code" out to be is drag and drop visual wizardry which makes re-use and system-wide consistency difficult.
regards,
Paul Watson
Bluegrass
South Africa
Ian Darling wrote:
"and our loonies usually end up doing things like Monty Python."
Crikey! ain't life grand?
|
|
|
|
|
Paul Watson wrote:
When you use MyXAML you are writing lines of code, nice code but still code IMO.
I don't really see MyXaml as 'code' in the traditional sense. Just like I don't consider HTML as code either.
Declarative Programming is certainly the future as far as I'm concerned.
Paul Watson wrote:
The way MS and others make "no code" out to be is drag and drop visual wizardry which makes re-use and system-wide consistency difficult.
There are certainly problems with the current wizards and code generation tools, but I think a lot of these can be overcome. And they must be overcome because 'typing' the same code over and over like your SqlConnection example is a waste of development time.
In my attempts to retool my business to be aimed at supplying software solutions to smaller businesses instead of (the now crapped out market) for larger firms, where I can no longer 'afford' to charge by the hour for development time, I have realised that only way forward is to completely rethink my traditional development methods. I've always had a dislike for auto-generating of code and drag and drop programming but I now thing that tools that reduce the development time and development costs are the only way forward.
MyXaml (another plug ) has started to help me achieve my goals. I now have a base CTI package that can be customised by altering the markup and the code-behind file without having to write lots of new code to achieve customers goals. (.NET has helped a lot too)
And now if I can get my MxCRUD stuff finished, I'll have the data input/access cracked too. This is the first place that I need to create a code generation tool, because it is a pain in the ass and time consuming to create the necessary StoredProcedure parameters markup. (Not as bad as having to write the actual code but still a waste of valuable development time)
And I've now got a few ideas on how to get towards the goal of 'Get Customers With Debt from Main Database' rather than having to write the archaic data-access code that we all hate doing but still find ourselves writing for each project we do.
Michael
CP Blog [^]
|
|
|
|
|
What genious. Why didn't I think of that!
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
And then retire early.
--
Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr.
Welle: Erdball - F104-G Starfighter
|
|
|
|
|
Wait till kids start retiring before they even start work...
regards,
Paul Watson
Bluegrass
South Africa
Ian Darling wrote:
"and our loonies usually end up doing things like Monty Python."
Crikey! ain't life grand?
|
|
|
|
|
The wait is over... some are born with money, some just don't give a f about anything, and some marry young and rich. I('ve) know(n) the 2 first stereotypes. I'm trying really hard to fulfull the last to 50%.
--
Ich bin Joachim von Hassel, und ich bin Pilot der Bundeswehr.
Welle: Erdball - F104-G Starfighter
|
|
|
|
|
Yup
and CP helps me achieve that (tons of fine code here)
so CP helps me make more money  its more powerfull than i thought 
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
|
|
|
|
|
is like asking, who would you rather loose, your mom or your dad?
...but, if i had to answer the question, the OBVIOUS answer is bug-free code. The single most important thing about code is, whether or not it works. Yes, we can all appriciate a well-designed, well-coded Types... but if the mofo doesn't do what it's suppose to, then who the hell cares?!
|
|
|
|
|
I disagree.
Take this case:
You have a good application, "that does the job". Almost. As a matter of fact,
measurement would show that the top 95% features are working perfectly, but
that there might be a bug in some of the bottom 5% of the feature set.
(This, by the way, IMHO, almost an industry standard. Do you thing that
MS Word ships when there is 0% bug ? Haha. I think not!;P)
Given a program that is easy to maintain, its easy to fix the bug.
As a matter of fact, for a small shop like where I work, its the only way
to know of the bug! I test my stuff all the time, but some of the features
are not used or almost never used. Its cheaper to have me work on newer
features that will generate sales and bring money in that spending eons
looking for bugs in features that we almost never use. Don't get me wrong,
those feature that are no longer being used a lot were tested a long time
ago, when they were written. But sometimes, well, I like to say that, like
our in our universe, where a pair of electron and positron gets created
simultaneously, a feature and a bug gets created simultaneously by me,
from time to time.
That is not to say that I make a lot of bugs. Its just for the sake of argument:
I'd rather be able to fix it because its so well written and obvious that it
makes one happy to be happy to see and fix a bug than spending 1,000,000,000
years testing an application. (Note that a large application may end up with
a lot of features)
|
|
|
|
|
good point.. hence why I said "stupid question". for this to be a valid arguement, more information would be necessary. We can argue endlessly maintainability against working code.
(but i rather have working code... i usually present the application to my clients, not the code... if the sh*t doesn't work, they could care less how modular the code is)
|
|
|
|
|
hehe... consider this, you need to present beta-1 of your code tomorrow 9am... which would you rather have? working code? or maintainable code?
I guess it's a consultant thing...
besides, if the code is harder to maintain, that just means more billable hours. NOT THAT I'M A CODE-PIG BTW! I love granularity.
|
|
|
|
|
I find that "billable hour" are not billable. 
It seems to me that nowadays, billable products or features are the way to go. I honestly evaluate how long something is going to take, and my bill goes with my evaluation.
|
|
|
|
|
My choice is: Writing code that can be understood by others
If it can be understood by others then it's been written in a clear enough manner that maintainability should be no problem. Chances are that this will also enable extensibility (though not necesarily). If it's easy to understand then it will be easy to find the places where optimisations (speed/resources) can be performed, and more importantly it will mean that you can get others with better skills than you to do some of the work. We're not all good at all things. And finally, easy to understand will mean it's easy to trace and debug, meaning the inevitable bugs will be easier to fix.
I'd like to say I write fast, efficient, bug-free code but I know that's a lie. I try to write code that makes sense, is easy to reuse, sensibly commented and structured enough so that others can work within my framework without breaking anything or being forced to use work arounds. All the rest should, given available time and resources, follow.
cheers,
Chris Maunder
Remember that a lone amateur built the Ark. A large group of professionals built the Titanic.
|
|
|
|
|
Well Chris, I think your opinion is worth a little more than two cents.
Chris Maunder wrote:
I'd like to say I write fast, efficient, bug-free code but I know that's a lie.
At lest you are honest.
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
My answer was also 'Code that could be understood' and spookily for very similiar reasons.
Must have something to do with teamwork!
Kevin.
|
|
|
|
|
Chris Maunder wrote:
My choice is: Writing code that can be understood by others
Great man thinks alike.
<font=arial>Weiye Chen
When pursuing your dreams, don't forget to enjoy your life...
|
|
|
|
|
Especially when they are schizophrenic...
>Great man thinks alike
regards,
Paul Watson
Bluegrass
South Africa
Ian Darling wrote:
"and our loonies usually end up doing things like Monty Python."
Crikey! ain't life grand?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
