Secure programming

ecksor

Hi.



I assume that anyone reading this board has at least a passing interest in security, and that this dicussion (assuming you all bear with me and respond ) will be of some interest to them.



Security knowledge and technologies are progressing all of the time. Cryptography, secure protocols, better architectures etc. Yet, there are many machines being compromised due to errors in the implementation of software systems. Buffer overflow, improper or no input validation, inappropriate trust etc. In my line of work, I review a lot of code, and come across a lot of very simple faults which can be easily fixed, and prevented if the developer is aware of such issues to begin with. In general, I find that this awareness is lacking. The result is a lot of faulty code. This makes any quality assurance techniques expensive for a business as time to fix becomes longer. This assumes that the quality assurance personnel have the expertise to spot the security flaws also, which is often not the case. Indeed, it assumes that the business uses any QA processes ...



Anyway. 2 questions arising out of the current state of things.



(1) - What do consumers of software think about this? How would you feel about paying for either off the shelf software or custom for your business software that is found to have easy to prevent security holes in it?



(2) - What do the people involved in producing software think about this? Do you think that things need to improve, and if so, what do you need to help it improve? Do you think I'm talking bull? If so, why? In particular, if any QA people are reading, I'm especially interested in their opinions and what they feel is lacking.



Thanks for your time.

ego

Hi,

I have an interest in "security" so hopefully I qualify to give you a response.

I am not a commercial developer, I do however have an opinion on poorly developed applications. I say poor because whilst they may be techincally beyond my ability making simple errors as you have phrased it is simply unacceptable.

Annalogy time:

A car manufaturer has certain requirements they must meet for ensuring a level of quality in their vehicles. A certain number of tests must be carried out in order to verify the road worthyness and indeed safety of a car before it can be sold to Joe Bloggs.

Why should software development be any different? And why should QC/QA only be applicable in say code for running nuclear power stations? I understand that the QA process extends beyond security, but I don't see a valid reason for it not including security. If your QA process does not validate for common security vulnerabilities (esoteric problems may always be unavoidable) then I think it is inherantly flawed.

This all comes down to what/how people are being taught. I wouldn't be surprised if you conducted a survey with 4th year uni grads from <insert favourite irish university here> on the advantages of using strlcpy over strcpy that the number of correct answers would be pretty low. Universities are simply teaching people bad programming techniques. My sister came to me a couple of months ago, she's a physic's grad, and she was asking me about goto statements as she had to use them for an assignment, go figure.


To answer your questions:

(1) I feel bad. I think that it is the responsibility of vendors to supply quality products to me as a consumer, irrespective of whether I am buying a hoover or a custom designed application for my web server.

(2) I don't produce commercial software, but I would expect myself to conform to quality guidelines if I did.

Thanks.

ecksor

Anyone who uses or writes software qualifies as someone whose opinion I'd like to hear, not just people with an "interest in security".

Anyway, doesn't everyone have an interest in security? How many people put their credit cards into online databases when shopping? Or other personal information. Or runs services and applications that take information from the internet. I mean, not everyone is a security guard or police officer, but you have an interest in the streets being kept safe ...

yellum

As someone who'd buy off the shelf software I'd be well annoyed if I spent money on somethng that was thrown together quickly and had sloppy code.

If there was some independent code auditing organisation out there that could give a ranking to software I'd follow their recommendations.

This type of watchdog is needed especially for server software. It should not be up to the likes of the various security groups out there to find holes in software voluntarily. A strict code of practice is needed for software developers. I'd happily pay more for server software if I knew that it had passed some security checks.

When giving my creditcard details to various websites I'd feel a lot happier knowing that they have been certified by an independent security tester who has passed some security auditors exam.

Is there such a thing at the moment ?

ego

"When giving my creditcard details to various websites I'd feel a lot happier knowing that they have been certified by an independent security tester who has passed some security auditors exam."

Well if you class rits as qualified auditors then they do provide something along these lines (check out their joint partnership with An Post). They are not government certified, so as you pointed out they are just some company who will find a vulnerability. How qualified or not they are to do this I have no comment or first hand experience.

To move away from the credit card issue and back to the big picture:

There are global standards for code requirements when submitting code for certification of security specifications - e.g TCSEC, CCITSE which gave us the wonderful Rainbow Books/C,B,A Ratings and EAL criteria respectively.

There would also be ISO standards which and ISO certified auditor could verify against. I have not read any of the ISO standards which would deal with quality assurance, however ISO is not renound for excellence. It would certainly not be as restrictive as CCITSE standards, however these would generally be too high from a commercial requirement and are generally only applicable to military grade requirements.

From the perspective of watchdogs you could look at the Security Systems Standards and Certification Act.

http://www.radium.ncsc.mil/tpep/library/tcsec/
http://www.radium.ncsc.mil/tpep/library/ccitse/
http://www.iso.ch/iso/en/ISOOnline.frontpage
http://cryptome.org/sssca.htm

Regards,
Dave.

ecksor

There are certication processes of software processes for quality such as ISO 9001 and the SEI Capability and Maturity Model (CMM). ISO 9001 concentrates on ensuring that your process can repeatedly deliver the same level of quality. However it is widely criticised as allowing someone to formalise a broken software process. As one German engineer said to me last week, he sees ISO 9001 and thinks "Ok, I know that they know how to spell 'quality'". CMM is more prescriptive in the measures it stresses which should promote quality within an organisation, but it comes down to the skill of the people involved essentially. The NSAs System Security Engineering CMM is more prescriptive again in terms of what practices it requires.

As regards independant testing, the most widely known certification of that sort is the common criteria used by the US government. This has been added to lately by the INFOSEC Assessment Methodology http://www.nsa.gov/isso/iam/index.htm
Unfortunately, the common criteria is expensive, and not justified for most companies. I think the IAM is a bit more realistic, but I don't know of any equivilents in this part of the world. There are equivilents of the common criteria in Britain and Germany (perhaps others).

yossarin

I think that a frequent problem is time to ship:

developers are quite often on a deadline. doing formal software specification (mathematical modeling, then FSM, then UML, etc) robustly takes time .consequently code enters states that the coder didn't anticipate, and presto: you've got holes.

what seems to be needed is a proper respect for the demands of security - the "strict code of practice" sounds good, but it'd have to be recognised as essential to every shmo who wants his mail to open itself. at the moment there seems to be peaks and lulls as each new super worm/trojan/etc. is invented, but imho security needs to be about more than responding to scares and viruses

in short: People who use software - if we just got rid of them, everything would be fine

Evil Phil

I agree with yossarin. Poor quality of software comes from the tight deadlines that developers are on. However this is a discussion on security. Personally I know very little about the subject. Although recently I've found myself having to know more so continue this thread with lots of links please, as I've a lot to learn.

ego

Why should I pay for a poorly designed/developed application just because it was delivered to me on time?

"Here is your new hand built <insert custom car here>. Take it easy going around corners as we had to rush the steering system to get it to you on the agreed date."

If that happened to me I would be quite annoyed.

The fact of the matter is that simple precautions can be taken and integrated into a development cycle to avoid common errors - not just security ones, you then account for this in your lead time. Ultimately you are doing a couple of things by employing QA into your development cycle:

(1) Improving the quality of your code - this has positive effects on your market image and customer confidance.
(2) Allow you to focus on enhancing your product by adding new services requested by customers etc - as opposed to spending XX months performing QA on your code after you have shipped it.

Do it right or don't do it all seems an appropriate snippet of advice which people should follow. I guess some programmers just need someone to tell them the difference between right and wrong.

I do appreciate that it is difficult if not impossible to account for all of the bugs, but from a security perspective things like buffer overflows, format string attacks, lack of proper input validation and race conditions can all be avoided if there is an awareness with developers in general, or at least an awareness with the person(s) doing the QA. Programmers should never audit their own code, but at least make sure the person doing so has the ability to.

Regards,
Dave.

Trojan

Originally posted by ego
Why should I pay for a poorly designed/developed application just because it was delivered to me on time?

"Here is your new hand built <insert custom car here>. Take it easy going around corners as we had to rush the steering system to get it to you on the agreed date."

If that happened to me I would be quite annoyed.

Deadlines are always going to be missed because of some reason or other, so you've either got to have infinite patience as a customer, or accept Yourdons idea of good-enough-software ( http://www.yourdon.com/articles/GoodEnuf.html ).

We don't ever get to a situation where we have "100%-perfect bug-free does-what-it-should" software, we should know where to cut back, sometimes it's quality, other times we just have to live with the missed deadline and make sure the product is fully tested.

So while I agree with 100% of what you're saying, and try to implement it, I believe that Yourdon is essentially correct and we need to understand what is "good-enough" for our customers, and strive to meet that goal, rather than 100% perfection.

Al.

ecksor

Evil Phil: I'm not suggesting that we ignore things like deadlines. This is a discussion about security, but it has to fit into the development lifecycle or it just won't happen. Personally, I believe that a certain level can be integrated with little or no extra time constraints, but it would require a change in thinking on the part of developers. As for links, I regularly collect links and put them on http://heap.nologin.net/programming.html
I'm also more than happy to answer any questions on the boards

Trojan: Thanks for the link. I think its a good description of the current state of software development. At the risk of attracting flames, I'd say that saying "Deadlines are always going to be missed because of some reason or other" is a cop out, and not very professional. I'm speaking as someone who has missed quite a few deadlines, so I'm not excusing myself from anything. It may be regarded as OK in the software world, but I don't believe it would be regarded as OK in other professions.

Why does quality result in a missed deadline? Do you feel that deadlines are badly negotiated? Incidentally, I'm not pushing for bug free software, that is too expensive, and as ego said, the Common Criteria is not suitable for everyone. (Incidentally, IBM recently committed to Sigma 6 for some or all of their projects lately, which is a defect rate of 3 per million lines of code.)

I realise this can be expensive, and Yourdon seems to be saying something that I would tend to agree with, that people are not willing to pay for quality. You say that we need to determine what is "good enough" and get to that level. I'm saying that "good enough" is not really good enough if you look at the level of assurance we as an industry are giving to the customers.

Perhaps the idea of certification and/or independant auditing will come into effect more. This is starting to happen, and it is being driven by the insurance companies.

Trojan

Originally posted by X_OR
Trojan: Thanks for the link. I think its a good description of the current state of software development. At the risk of attracting flames, I'd say that saying "Deadlines are always going to be missed because of some reason or other" is a cop out, and not very professional. I'm speaking as someone who has missed quite a few deadlines, so I'm not excusing myself from anything. It may be regarded as OK in the software world, but I don't believe it would be regarded as OK in other professions.

Well, for one thing, this is a relatively new profession, we've only been coding since WW2 or so, and only been doing something that could be even remotely called "engineering" since the early 60s. We've also got a huge confusion of different platforms, methods of implementation etc. I'm no expert in physical engineering, so I'm wondering if they have a comparable number of solutions to a single problem as we have: that makes it damn hard to judge a deadline correctly, which is essentially what this mini-discussion is about, right?

Estimation is allegedly a science, but it seems to me and many others to be either an art-form, or maybe just pure magic. If you liked the last link, have a read of these.

http://members.ozemail.com.au/~thomsett/articles/games.htm

http://www.enterprisedev.com/upload/free/features/entdev/2000/06jun00/bp0006/bp0006.asp

Originally posted by X_OR

Why does quality result in a missed deadline? Do you feel that deadlines are badly negotiated? Incidentally, I'm not pushing for bug free software, that is too expensive, and as ego said, the Common Criteria is not suitable for everyone. (Incidentally, IBM recently committed to Sigma 6 for some or all of their projects lately, which is a defect rate of 3 per million lines of code.)

I realise this can be expensive, and Yourdon seems to be saying something that I would tend to agree with, that people are not willing to pay for quality. You say that we need to determine what is "good enough" and get to that level. I'm saying that "good enough" is not really good enough if you look at the level of assurance we as an industry are giving to the customers.

IBMs clean room standard was what, if you had more than 1 bug per 1KLOC you had to rewrite the whole module from scratch? Something like that, can't recall exactly but that's close. Fair enough, sounds a bit harsh but I'm sure you come up with some damn fine quality.

But don't forget, IBM are a company who takes 9 months to ship an empty box. They have ~ 300,000 employees, a hell of a lot of developers: they can afford that. XYZ Software down in Fairview park can't.

Originally posted by X_OR

Perhaps the idea of certification and/or independant auditing will come into effect more. This is starting to happen, and it is being driven by the insurance companies.

Yeah, from what I recall, the Software Engineering Institute have been working with various orgs like the IEEE to develop some sort of "Certified/Licensed Software Engineer" programme. Have a look at http://www.sei.cmu.edu/ for more info, also http://computer.org/software/articles/Speed.htm for a legal perspective.

Sorry to take this slightly off-track, but I find this very interesting

Al.

ecksor

I'm going to try not to hog this thread too much, since I'm mainly trying to find out what other people think the problems are and how to solve them but I wanted to clarify a couple of points.

Firstly, I'm not advocating Sigma 6 for XYZ software company. I realise that level is expensive, and that level isn't necessary for all applications. It was just an example (possibly extreme in this context) of what is possible.

Secondly, you talk about something like estimating work as being an art. Some programmers even consider what they do to be an art. I disagree. We should think of ourselves as engineers and work accordingly. Then again, as anyone who has employed me as a programmer will tell you, I'm not very good at estimating my time (although I'm getting a lot better).

I find it interesting that you compare software engineering with physical engineering. You are completely correct that we are a new profession but I feel that there is a certain distaste for good software engineering principles amongst many programmers. I think we can learn a lot from these disciplines, but I also think we have the know-how to do things properly. The safety industry and the military can do it with software after all. Again, I'm not suggesting we all start aspiring to that level, I'm merely saying that the knowledge is around.

You raised the point of other disciplines not having as many possible solutions to deal with. Should we start resisting the urge to use the latest toys and use what we know best? [1]

I don't think you're taking things too far off track, and I find this interesting too

Again. Do people feel that the level of quality is below what it should be in general software production? Why is that? What is stopping us from improving? How should we be trying to improve?

I'm focusing from the point of view of security, but any quality issues are relevant I think.

I'll read those links now. Thanks.

[1] http://www.securityfocus.com/templates/archive.pike?list=98&start=2001-04-26&mid=180627&threads=0&fromthread=0&end=2001-05-02&

The Corinthian

Originally posted by Evil Phil
I agree with yossarin. Poor quality of software comes from the tight deadlines that developers are on.

If I might add to this, another related factor on the job training. Firms cut corners, hence tight deadlines, however another corner that is frequently cut is training of any description. It's quite commonplace to find programmers learning new technologies or languages on a client's time. Other than the learning curve eroding available time and exasperating the deadline issue further, how high will the quality of any software be coming from someone who is a complete newbie?

This is not only an issue for security reasons but even reasons of preferment and scalability. A VB programmer beginning Java is likely to prefer the use of strings over stringbuffers for text manipulation while a Java programmer beginning VB is likely to forget to destroy the objects they create. Much of the knowledge in good coding comes from experience and formal training.

A year and a half ago, I got pushed (admittedly eagerly) into developing the wireless portal for one of the telcos. In Java, where my skills stretched as far as Hello World on the onset of the project. Looking back on it, there are many things that I would not do again and many that I could have improved upon, in my code.

Lack of proper mentoring and training by firms is not only to blame. I’ve never understood how some programmers just don’t code in their spare time. They should know by now that it’s not just a nine to five job (if such a job exists anymore). Coding in your spare time is worth a dozen training courses, imho.

yellum

I think some major organisation should just decide in the morning that all software being purchased and used must meet new security standards. It was like when the US Military adopted SGML. Anyone that did busness with them had to use it then.

Or like a story about US Beef Processes. The US Govt. wanted to change the way beef was farmed and processed. They gave up after a study showed it would cost too much and take decades to implement the changes. BSE hits Europe, McDonalds tells US farmers this is the new standard and the new standard was adopted by the majority in a few months. More power that the Govt to make changes.

This might be what is needed.

p

I think that the very basic programming mistakes,
varying from security though usability through to memory issues can all be fixed within companies both big and small. This issues are due to the immature nature of the technology world. You can see the same types of issues in web design companies as readily as software development companies.

Basic education and more informed clients will help eliminate the basic, yet funadmental issues.

And for most software products that is all i'd demand or expect.

I'm reminded of the car crash/recall thing in fight club. It's the same with software companies, it's cheaper to release a patch than test it throughly.

http://www.fastcompany.com/online/06/writestuff.html
Is a very good article about the software that is written for NASA.
Obviously their testing is extreme but some of the ideas in it are in my opinion quite interesting.

The idea of people pulling latenights to get projects done is common place. The industry needs to grow-up and learn to manage projects properly. Coding till 2am isn't the way to go.
It should be a nice 9-5 job where people come in do their work and leave.


Now I know that doesn't sound very exciting, and I think that's why the industry is the way it is. College grads like the life-style of pulling projects out of a hat at the last minute, they're young, they don't want to be in at 9 every day.

As programmers grow older and have children I think that they'll themselves not want to be working late nights near project ends. Hopefully projects will reflect this as they are better planned and those not able to work steadily themselves will have a schedule they have to stick to.

People make mistakes, people are uneducated and people are downright lazy and procrastinators. It's up to the proccess of developing software to allow for these things. At the moment, there isn't much of a process at all.

- Kevin

spod

Just on the subject of ISO9001 certification...

Worked for a place that was ISO9001 certified many years ago.

From what I can recall, if you wanted you could probably ISO9001 certify shooting yourself in the foot, as long as you were willing to do all the documentation and described the procedure adequately

ecksor

WRT to certifying the process of shooting yourself in the foot. Its what I was saying about formalising a broken process. Of course, if you want to shoot yourself in the foot repeatedly, then an ISO certification should guarantee that you do it with the same quality every time you try it. The trick is to make sure that you do want to shoot yourself in the foot.

After reading the links by Trojan about estimation, it seems that in most cases the software was falling down due to inexperienced management, or management not understanding the needs of developers. (I sense that this will ring a few bells with people ). That raises a good point, that improving the software quality requires a management committment, both from the point of view of making sure that the developers have the resources they need, and to make sure that developers will take any new initiatives seriously. Agree/Disagree?

I like the article that p linked to. It describes a software process that is frankly not practical for nearly all software companies, but it does point out the fundamental parts of the process that can be adopted to improve quality significantly, which do not necessarily have to be prohibitively expensive.

Trojan

Ok, since we're talking about how to ensure quality code, have any of you guys used the PSP (Personal Software Process - http://www.amazon.com/exec/obidos/ASIN/0201548097/qid=1000768121/sr=1-1/ref=sc_b_1/102-1070066-8920142 )

I found it could work, but too many docs for it's own good, which is where a lot of these processes fall down, we need to be able to implement a process with less overhead than the 40,000 page doc for a 6,500 line change as mentioned on that NASA article.

More coherent thoughts tomorrow

Al.

yellum

That FastCompany article rawks. This idea should be encouraged more, though when you look at their budget .... and the time to implement it...

Trojan

The kind of discipline needed to promote this culture is not being taught in our colleges, it's the hero-programmer all-nighter type culture that we all know and love. This is continued in software houses as new blood comes in and the older hackers pass on their culture.

To achieve the kind of results the NASA boys and girls are getting we need to get away from that, but I don't see it happening in any software dept or company for a long time. As you said XOR, this requires serious commitment from manglement, and they're not going to take that kind of risk until customers start demanding it.

Al.

ecksor

Ok, lets see what we've got so far

No one has come out and said that there isn't a problem. There is a lot of pessimism about the likelihood of a change I think? As I've said before, I'm not talking about NASA's level of quality, but is it really expensive to adopt some of the process changes that they talk about? Work 9 to 5, encouraging better use of time and planning. Peer review of code. I personally believe that unless you are a one person operation, there is no excuse for only one pair of eyeballs ever seeing production code, and that's without ever even thinking of the security implications. Agree/disagree?

I know there is a lot of scepticism in terms of the cost of this and who's going to pay for it, but I don't view it like that. I believe you can save a lot of money in maintenance of software and lost project time by planning and adopting the software engineering principles that a lot of people are dubious of. I think Trojan hits on a very important point in the "hacker culture" also.
At any rate, if this thread only got companies to think "Hey, lets actually read each other's code and have some input into it", then I would think that the world is a better place. Will this fall down in the culture Trojan talks about? Will egos be hurt? Will prima donnas object? Does it make sense for your business and for the quality of your projects to pander to them?

Anyway, for software folk, stepping back from the bigger picture (although I'd welcome and encourage any new ideas or opinions on that) and concentrating on your own area of expertise, what do _you_ need to help improve this? I think that changing the way that software companies think is an important step, but a lot of problems will arise from the basic implementation of the software. This comes down to the nuts and bolts, line by line software development that programmers do. Improper input checking and trust as I mentioned in my first post. Why is this? Programmers are not stupid, and they're not generally people who shy away from learning, if they were they'd be in another line of work I think. So, what's up? What's missing? What do you need?

Do architects and QA people feel competent to securely protect the systems they design, or look for and test for vulnerabilities, respectively? If not, why not?

Keep it coming

seamus

1)Yep, I'd be pretty píssed off too if there was sloppy code in something I bought *cough*Windows*cough*. Has anyone ever used Mathcad? It's possibly the most bug-ridden piece of shít I ever used, and they charge universities an arm and a leg for it. I never paid for it at home though so I don't really mind (except when trying to finish a report at 12 midnight and it keeps telling me that the 'x' array isn't defined, when in fact it's obviously defined on the page above it grrrr)

2) I don't develop commercial software(yet) but anything I write, I use, so obviously I clear out as many flaws as possible, 'cos it's not a timesaver when you have to shut it down every 5 mins or it won't accept a certain input.

Evil Phil

Ok, I think the things I need done by myself and my employer to improve the quality of my code are:

• Deadlines
  Realistic deadlines need to be set. Things that aren't going to be finished should be left out for a later release, or if they've been promised the deadline should be pushed out until they're finished.
  I know that companies loose money if they miss a delivery to a customer, and then the customer complains about the bug count. So they should include this in the project design and plan. Which brings me to my next point.
• Design
  More often than not my design documents are little more than specifications. I then do a more formal design myself although this is not required by management. The projects I've worked on where the design has been formalised and QA'ed, before any code is written, have gone a lot more smoothly and produced a better end product.
  Letting developers do there own design and hoping that everything fits during integration testing is a bad idea, period.
• Testing/QA
  Peer code review is vitally important, even if it takes time. I wouldn't mind staying late for a couple of days to do this. It saves time in the long run.
  NEVER test your own code.
  The design should be tested before coding begins.
  White box/black box testing. I've learned it in college I've never seen it in practice except in one company who produce very high quality software.
• Training
  New staff should be given training into the companies particular field of development with practical sessions. You're going to be doing stuff at home anyway. (The Corinthian had a good point on this: Code at home)

Opinions?


[later]
I've just reread this post and it all seems fairly obvious to me. It does relate to my present job, and makes me ask "Ffs, why aren't they doing any of this?". Anybody else in this situation?
[/later]

ecksor

As a programmer what do you think of the focus given to security issues when learning to program, or of the availability of secure programming resources? Same applies to people reviewing code.

What is missing in this area?

Trojan

Evil Phil: lot of good points there, but you don't address the issue of a process: all those items you've listed need to be tied together in some way to make this work.

Re deadlines: do you think it's an issue of them being set too close and code rushed through? Or is it just that due to the lack of process, what would normally take x takes 2x + ?

To answer your last question: yes, I had come accross this problem in the last place I worked, haphazard processes, no peer review, little priority given to testing, etc.

Luckily in my current job there's a highly formalised process for everything, and all code changes must be peer reviewed by several co-workers and then again by a 3rd party before integration. I'm not sure what we have to go through to add brand new code, but I'm fairly certain it'll be rigorous.

XOR: almost zero focus is given to these issues when learning or being taught, unless you've got a cool lecturer who is aware of, and cares about, these things. I think that those people from a systems level unix programming background will have a strong knowledge about secure programming, but those from other (esp. DOS/Windows) backgrounds may not.

What should be done? Read those secure programming links you had up earlier, maybe make a list of calls not to use (or how not to use them), ones to be wary of, do some practice coding with some buffer overflows and things, and basically find out how code is broken, and how to avoid that. And above that, at a higher level, try and put some of those things that Phil talked about into practice.

Al.

ecksor

I had a pretty good idea that the answer would be "no focus", but I also asked what you thought of this situation?

By all means read the links that I collect, there's some very interesting stuff there on how to write programs securely and how to break insecure ones. What else could be done that you think would be helpful though? Once someone has started reading those links there is a certain level of awareness that I don't think everyone has ...

I've been kicking around the idea of doing a basic introduction to secure programming principles and where applications often tend to fall down in my security audits. Do up the obligatory power point slides and convince someone to give me a lecture hall for a saturday afternoon and start talking too much etc etc. Would anyone be interested in this? What technologies and languages would be of most interest? What else would you find relevant? Answers on a stamped self-addressed followup here.

Trojan

Well I see that this thread has been mentioned on the CLUG list - which of you is Damien btw? I know it's not Jerry... so maybe some of the ILUG crowd could come up with a venue for you. I for one would be interested.

Al.

Evil Phil

Righty:

Well you've a better idea of the content than I do. Java, vb, jsp and asp would be relevent to my job. I'd like to find out about SSL on windows as well. I know a few people who would probably come along.

I'm a member of the B.C.S. and after having a look at their web site (I really should do that more often) I've found their software protection group. Not the prettiest site but it's seems to have good content.

<= (That's number 600)

p

Someone brought up the point of coding at home.
Now maybe it's just me but I don't see that as part of your job.

You should never be expected to code at home and if you are you should be getting paid alot of money to make up for it.

A company should train to you to bring up your skills from what you had when they hired you to what you need to develop some software.

Often people's coding at home is dabbling and relying on what people have taught themselves for fun, for a production piece of software is not a good idea.

- Kevin

Trojan

Hey P! Just want to clear up a some confusion!

Originally posted by p
Someone brought up the point of coding at home.
Now maybe it's just me but I don't see that as part of your job.

It's not part of your 9-to-5 job, no. You're dead right there.

Originally posted by p

You should never be expected to code at home and if you are you should be getting paid alot of money to make up for it.

Yep.

Originally posted by p

A company should train to you to bring up your skills from what you had when they hired you to what you need to develop some software.

Here's where we go off-track: yes, the company should train me, but no training course is going to teach me what hours of coding at home will. If I undergo their training alone, I will probably be able to do my job, and that's great.

But I am in charge of my own career, including making myself look good for advancement, for getting on good projects, and making myself look as attractive a hire as possible. I need to develop skills and update with new technologies as much as possible. Coding at home lets me do that.

I'm certainly not going to be working on my current work project at home though!

Originally posted by p

Often people's coding at home is dabbling and relying on what people have taught themselves for fun, for a production piece of software is not a good idea.

- Kevin

Also don't forget that a lot of open source stuff is production quality, and most of it was written in the days before corporations starting sponsoring it.. it was the hackers at home.

Ok, hopefully that's cleared up the confusion.

Al.