Code is comprised of simple rules that move values around the memory in a computer. Software, on the other hand, is often complex because of the required interactions with humans. If a software function is always called by another piece of software, it's more predictable and easier to code correctly, but once you make it ready for humanity, you have a lot of non-code-writing variables to consider.
Software "developers" are called developers because the code in a piece of software develops along with the discovery of human needs. An end-user might want to be able to use the software on a mobile device and another without internet connectivity entirely. For this reason the software can always be changed, updated, and improved -- given enough time and resources.
Humans + Hardware, together, create a huge number of possible combinations. This can make it difficult to feel like a piece of software is ever complete. The key to being able to finish a software project is to draw very clear boundaries. Much like how land is divided along lines of ownership to prevent an architect from building on the neighboring property, the software engineer must know where he must stop so the software can then be put in the hands of the users. Once the engineer's map is plotted, it's then just a matter of starting with simple functionality and methodically integrating the human ideas into toward a useful tool.
Software "developers" are called developers because the code in a piece of software develops along with the discovery of human needs. An end-user might want to be able to use the software on a mobile device and another without internet connectivity entirely. For this reason the software can always be changed, updated, and improved -- given enough time and resources.
Humans + Hardware, together, create a huge number of possible combinations. This can make it difficult to feel like a piece of software is ever complete. The key to being able to finish a software project is to draw very clear boundaries. Much like how land is divided along lines of ownership to prevent an architect from building on the neighboring property, the software engineer must know where he must stop so the software can then be put in the hands of the users. Once the engineer's map is plotted, it's then just a matter of starting with simple functionality and methodically integrating the human ideas into toward a useful tool.
The past year I've come to fall in love with the idea of rigid/concrete boundaries with soft/flexible cores. Most projects follow the inverse composition (concrete core / flexible boundaries)
What the former means is that you have a lot of control over the implementation details of some sane end goal that you've specified.
Best example of the latter is when a team's PM says We need to do X... and then next week they come in and say. client now wants Y and Z. They keep adding to the specs.
I can't say it better than the way Basecamp's Ryan Singer does though. I've found his Shape-Up book to be an accessible primer on this method of making.