What is the difficult part of software development?

Question

What is the difficult part of software development that has major impact on final product/output? and How?

What I expect is, in which areas [like technology, requirements..ect] should I concentrate 'more' to develop better applications.

Answer 1

The difficult part of software development is communication: between you and your team members, business partners, customers, and other stakeholders. It has the biggest impact on the final output. These will take the form of written and oral requirements, best practice communication, etc.

If you get this right, and have developers with some talent, the technology part will take care of itself by comparison.

Answer 2

In my experience, i try to follow an old saying: "Measure twice, cut once." The more time you spend on requirement gathering and design, the more quickly and cleanly you can actually implement and test your code.

As many other answers have agreed, communication is of paramount importance and depending on the people you work with, can be challenging or nigh-impossible. Requirements are rarely set in stone, and if your bosses / customers are constantly changing what they want you to do, or piling more and more features on top of your project, it will be hard to design. With incompetent managers or bosses that change the requirements of your project weekly, you may find the hardest part of software development is actually developing software.

Answer 3

Communication, communication and communication. In projects that I have participated in, success (or lack thereof) has almost exclusively been related to the ability to talk to the customer, who is very seldom a programmer (apart from having a team of competent developers, that is).

Answer 4

The most difficult part is dealing with human beings. God i hate them!

Answer 5

Planning. Especially if you're lucky enough to work on different type of projects every time. A planning to create yet another web community is not too hard, and one could almost say that such projects are more about configuration (even when using a programming language) rather than software development. But a planning for a totally new project, probably involving some new techniques, I've always found the hardest part.

Answer 6

If you are developing in a large enterprise you need to balance the strategic direction as laid out by enterprise architects with more tactical concerns of the project manager.

Answer 7

The first hard part is communication. If you are using a traditional prescriptive development model, this means making sure that your requirement and specification documents are correct. And by correct I mean that both the development team and the customer are in agreement ("But I wanted feature Y!"). Using a more agile approach (where you don't really write up formal requirement documents), you have to be in CONSTANT contact with the customer and your stakeholders (marketing, management, etc). Agile can get away with not having huge requirement docs by always being in constant communication.

After communication, I'd say the next hard part is testing. No one likes to write tests. Its boring. Its repetitive. But, it means that you can do automated regression testing whenever code is added or changed in your project, AND, good unit tests can serve as great API docs for other developers on your team (how does method X work? read the test).

After testing, I'd say scheduling is next. You might not be as exposed to this unless you are a project manager, but coming up with a good development schedule that has enough wiggle room (in case something runs late, etc) can be a pain.

Answer 8

I'll shamelessly parrot Steve McConnell's line from Code Complete, the overarching difficulty of software development is: Managing Complexity.

Managing delivering features vs. schedule vs. code quality.

Managing making the right features vs. getting features done.

Managing requirements, communicating with customers sufficiently to gain confidence that what you're building is actually what the customer wants.

Managing coordination between teams and components. Managing the integration of a system with many parts, each part built by different hands and dependent on other parts in the system.

Managing team and individual dynamics.

Managing the right amount of oversight, tracking, accountability, planning, and analysis to balance development velocity with development quality and predictability.