Am I suited to work in software devlopment?

I wonder if I should continue to get a degree in software engineering because I think the work envoirments are a bit to much centered around verbal and direct communication for me. I'm not a very good verbal communicator and in agile teams this seems to be a very important factor as the whole development process is basically centered around constant verbal communication. And the open office layout also contributes to the feeling that I'm not really at my place in most software factories, because I need some privacy and can't stand to work in an envoirment with constant noice of other people talking.

I'm interested in computer science and like programming but the work envoirments seems to spoil it a bit for me. So what would you guys advice me, should I stop the study or look for a better place to work. Are there work envoirments in software engineering better suited for my personality?

[deceptikon]

I think the work envoirments are a bit to much centered around verbal and direct communication for me.

Good luck finding any lucrative career that isn't. Rather than running away, you should be working to improve your communication skills.

in agile teams
And the open office layout

Want to know a secret? Full agile isn't as popular as agile folks would like you to believe, and related practices such as pair programming and open offices are actually pretty rare. Most companies that use agile will design a watered down subset of it to suit their needs without forcing them to adopt a completely (pardon the term) "hippy" style of software development.

Yeah you are right, I guess that verbal communication is the backbone of each career in the commercial business world and that I should work on it. Nevertheless I think communication in software engineering is sometimes pure chaos because of the constant change in requirements and the constant arrival of new technical problems which are never encountered before. I like programming but not so much in a professional setting with the constant ad-hoc communication, lack of time, and where everything is floating in your colleagues heads instead of in documents.

But I thought agile methods where on the rise. For example: "scrum" is a practice widely used and is basically about pieces of paper floating all over the office walls with all the tasks written on it. The view of it alone is enough to drive a person crazy. They should use software development software like jira in my opinion:
http://www.atlassian.com/software/jira/overview

Well if I had my own software company, everybody would have his own office and communication would be going with chat as much as possible. There would be regular personal meetings but only when necessary. This way the productivity is much higher because programming is a mind game which should not be disturbed constantly. We should not let our profession get ruined by management people who understand nothing of what software development is about.

[deceptikon]

Nevertheless I think communication in software engineering is sometimes pure chaos because of the constant change in requirements and the constant arrival of new technical problems which are never encountered before. I like programming but not so much in a professional setting with the constant ad-hoc communication, lack of time, and where everything is floating in your collegeau's heads instead of in documents.

Is this speculation, an opinion based on hearsay, or do you really have some sort of experience with the environment? In my years working as a developer and consultant, I can't say that I've seen any companies that could be described as "pure chaos". In fact, the changes and deadlines are often handled quite well.

I'm also starting to wonder what you mean by "ad-hoc communication" and how this could possibly be considered a bad thing.

But I thought agile methods where on the rise.

Claiming to be agile is on the rise. Actually being agile to the point where a fan of the methodologies would agree, not so much.

Well if i had my own software company, everybody would have his own office and communication would be going with chat as much as possible.

In my experience, it's faster and more effective to discuss things face to face, or at least over the telephone. Chat is relatively slow if you're in the same office space, and it's difficult to convey complex ideas without hand waving and a whiteboard. Often there's a lot of Q&A going on, which works better face to face as well.

I'm not big on talking to people either, but I can still see the necessity of it.

This way the productivity is much higher because programming is a mind game which should not be disturbed constantly.

There's a difference between avoiding being disturbed and going out of your way to make communication difficult. I don't think daily planning meetings are a good idea, but a brief weekly meeting to keep track of what everyone is currently working on and voice concerns is helpful. Ad hoc meetings should be encouraged for when a quick gathering can be meaningful, but not required.

[pritaeas]

I don't think daily planning meetings are a good idea

We use the standup from scrum daily, and I must say that I am pleased with it (although we are not using anything else just yet). It doesn't take long (20 mins tops with 18 people), and everybody is up to speed with what happened yesterday, and what is planned to happen today. So any questions you have can be addressed to the right person quickly later on. You can determine bottlenecks or problem areas at an early stage too.

[deceptikon]

and everybody is up to speed with what happened yesterday, and what is planned to happen today.

I suppose it would depend on how quickly things happen and the size of the team. If you organize tasks and milestones with the kind of granularity that would produce significant changes from day to day as opposed to week to week, then daily meetings are justified. In my experience that's not productive, but I also work in a fairly small company where questions can be addressed by walking over to someone and having a chat or updates are along the lines of leaning over and saying "hey, what are you working on right now?". ;)

Is this speculation, an opinion based on hearsay, or do you really have some sort of experience with the environment? In my years working as a developer and consultant, I can't say that I've seen any companies that could be described as "pure chaos". In fact, the changes and deadlines are often handled quite well.

I'm also starting to wonder what you mean by "ad-hoc communication" and how this could possibly be considered a bad thing.

Most software companies are constantly operating on the edge of innovation in their markets ( I worked as a tester in such a company ) so there seems to be a constant change in requirements and techniques which result in a lack of time to properly document the software architecture and functions. So this is what I call chaos, because this way I can't understand a system without constantly asking a colleague how something is supposed to work and which classes form a certain function.

So what I basically mean with constant 'ad-hoc' communication is the constant need of communication about technical details that should have been documented.

But maybe you work in a less innovative software company with a stable product portfolio?

[pritaeas]

should have been documented

This is the key. Any required change should be documented in some way, whether it is in actual documentation or a feature/bug request.

how something is supposed to work and which classes form a certain function

This should be entirely clear/reflected in the source/unit test.

[deceptikon]

But maybe you work in a less innovative software company with a stable product portfolio?

Or maybe you've worked in a company where the R&D department is poorly managed. ;) I work as a consultant, and as a result see how many different companies of different sizes work. And while I've seen some scary shit in terms of management and processes, even the companies that are on the cutting edge of innovation or have to deal with constant change haven't struck me as being chaotic.

I'm not sure what to say at this point because it doesn't seem you can be convinced that the development environment of every company isn't a clusterfuck. I can only conclude that you've already made your decision to not become a developer, so there's really no point in continuing this discussion.

This should be entirely clear/reflected in the source/unit test.

In the source code you can see what the function of class is but not so much the interaction it has with other classes. So if I'm supposed to write automated tests for a certain function, I need to know which classes interact with each other to form that function.

You can of course import the source code in a program like enterprise architect to generate a class diagram and see the relationships but for large software projects this becomes a mess. So basically these things should be documented in sequence diagrams in which you can quickly see the relationship between classes for certain functions.

But this is far to much work for most software companies, so then don't bother asking someone new to automate the testprocess but let the lead developer do it himself.