Some Problems and Solutions in Software Development
Software development is a difficult task. Trying to develop high-quality software is a complex problem. In this weblog entry, a bunch of aspects – problems as well as solutions and best practices – will be displayed, motivated by several resources.
Five Common Problems in Software Development
In a quite lengthy FAQ there is a list of five common problems in software development:
- poor requirements: One problem is interdisciplinary oroientation of key persons.
- unrealistic schedule: Who makes the schedule? Could be that not the right (competent?) persons are involved.
- inadequate testing: Use unit tests, no one can do integration tests until hell.
- featuritis: Easy to follow as today’s technology offers sooo much and one would like to have it all.
- miscommunication This is as in everyday’s life.
Five Common Solutions in Software Development
The same FAQ also shows up with five common solutions:
- solid requirements: opposite to poor requirements 🙂
- realistic schedules: Involve the right persons, don’t expect a 60 hours week of the developers.
- adequate testing: Use xUnit (Junit for Java, e.g.), do frequent integration tests.
- stick to initial requirements as much as possible: Well, this is dependent on the type of relation with the customer. Agility offers some different approaches, but maybe they could be unrealistic.
- communication: Do reviews, stand-up-meetings, shorten communication paths.
Best Practices in Software Development
I find the Best practices for effective software development quite useful, although they should be moreor less intuitive. Here is a short extract (headings taken from the given URL):
- Place a strong leader in charge of the overall project: This especially is necessary if there a two divisions with different interests.
- Plan your software architecture incrementally: This has something to do with AGILITY: Extracting some Essentials.
- Do a post-mortem: Very important and should be a fundamental piece of every project. After finishing the project check out what succeeded, what failed, what went wrong and why!
- Divide long projects into smaller pieces: This is a theoretical target and not realizable for any project. If possible, then it comes closer to a Service-Oriented Architecture: What’s up with it?, whatever you name with that.
Antipatterns became popular with introduction of several books on this topic. Watch out the resources section to find out more.
An antipattern is a structure that can be identified and leads to the conclusion that something went wrong, so to say.
Here are some architectural and management antipatterns defined as follows, to make things more concrete:
This Architectural Antipattern should be well known to most developers. The Spaghetti Code Antipattern is defined by the Synopsis “An ad hoc software structure makes it difficult to extend and optimize code.”
Mushroom Management is a Management Antipattern. It is defined as: “Mushroom management is when the project manager treats people the way we raise mushrooms — we keep them in the dark and feed them a steady diet of manure. The assumption is, ‘You do your little value-added work and you do yours, and I’ll pull all the strings together.’ What that really says is, ‘I don’t trust you as a group, and I certainly never bothered to develop you as a team.'”.
My favorite one besides Mushroom Management. Again a development antipattern. In the Antipattern Wiki defined as:
“Problem: You need to choose a technology for your development.
Context: You need to develop some new system or piece of software that doesn’t fit very well the technology that the development team are familiar with.
Supposed Solution: Use the familiar technology anyway. The technology (or concept) is applied obsessively to many problems.
Refactored Solution: Expanding the knowledge of developers through education, training, and book study groups exposes developers to new solutions.”