1. Introduction to Software Development
Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be anyno inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to see twofold gains every two years.
Frederick J. Brooks, Jr.
So, youre asking yourself, why is this book called Software Development, Design and Coding ? Why isnt it called All About Programming or Software Engineering ? After all, isnt that what software development is? Well, no. Programming is a part of software development, but its certainly not all of it. Likewise, software development is a part of software engineering , but its not all of it.
Heres the definition of software development that well use in this book: software development is the process of taking a set of requirements from a user (a problem statement), analyzing them, designing a solution to the problem, and then implementing that solution on a computer.
Isnt that programming, you ask? No. Programming is really the implementation part, or possibly the design and implementation part, of software development. Programming is central to software development, but its not the whole thing.
Well, then, isnt it software engineering? Again, no. Software engineering also involves a process and includes software development, but it also includes the entire management side of creating a computer program that people will use, including project management, configuration management, scheduling and estimation, baseline building and scheduling, managing people, and several other things. Software development is the fun part of software engineering.
So, software development is a narrowing of the focus of software engineering to just that part concerned with the creation of the actual software. And its a broadening of the focus of programming to include analysis, design, and release issues.
What Were Doing
It turns out that, after 70 or so years of using computers, weve discovered that developing software is hard. Learning how to develop software correctly, efficiently, and beautifully is also hard. Youre not born knowing how to do it, and many people, even those who take programming courses and work in the industry for years, dont do it particularly well. Its a skill you need to pick up and practicea lot. You dont learn programming and development by reading booksnot even this one. You learn it by doing it. That, of course, is the attraction: to work on interesting and difficult problems. The challenge is to work on something youve never done before, something you might not even know if you can solve. Thats what has you coming back to create new programs again and again.
There are probably several ways to learn software development. But I think that all of them involve reading excellent designs, reading a lot of code, writing a lot of code, and thinking deeply about how you approach a problem and design a solution for it. Reading a lot of code, especially really beautiful and efficient code, gives you lots of good examples about how to think about problems and approach their solution in a particular style. Writing a lot of code lets you experiment with the styles and examples youve seen in your reading. Thinking deeply about problem solving lets you examine how you work and how you do design, and lets you extract from your labors those patterns that work for you; it makes your programming more intentional.
So, How to Develop Software?
The first thing you should do is read this book. It certainly wont tell you everything, but it will give you a good introduction into what software development is all about and what you need to do to write great code. It has its own perspective, but thats a perspective based on 20 years writing code professionally and another 22 years trying to figure out how to teach others to do it.
Despite the fact that software development is only part of software engineering , software development is the heart of every software project. After all, at the end of the day what you deliver to the user is working code. A team of developers working in concert usually creates that code. So, to start, maybe we should look at a software project from the outside and ask what does that team need to do to make that project a success?
In order to do software development well, you need the following:
A small, well-integrated team : Small teams have fewer lines of communication than larger ones. Its easier to get to know your teammates on a small team. You can get to know their strengths and weaknesses, who knows what, and who is the go-to person for particular problems or particular tools. Well-integrated teams have usually worked on several projects together. Keeping a team together across several projects is a major job of the teams manager. Well-integrated teams are more productive, are better at holding to a schedule, and produce code with fewer defects at release. The key to keeping a team together is to give them interesting work to do and then leave them alone.
Good communication among team members : Constant communication among team members is critical to day-to-day progress and successful project completion. Teams that are co-located are better at communicating and communicate more than teams that are distributed geographically (even if theyre just on different floors or wings of a building). This is a major issue with larger companies that have software development sites scattered across the globe.
Good communication between the team and the customer : Communication with the customer is essential to controlling requirements and requirements churn during a project. On-site or close-by customers allow for constant interaction with the development team. Customers can give immediate feedback on new releases and be involved in creating system and acceptance tests for the product. Agile development methodologies strongly encourage customers to be part of the development team and, even better, to be on site daily. See Chapter for a quick introduction to a couple of agile methodologies.
A process that everyone buys into : Every project, no matter how big or small, follows a process. Larger projects and larger teams tend to be more plan-driven and follow processes with more rules and documentation required. Larger projects require more coordination and tighter controls on communication and configuration management. Smaller projects and smaller teams will, these days, tend to follow more agile development processes, with more flexibility and less documentation required. This certainly doesnt mean there is no process in an agile project; it just means you do what makes sense for the project youre writing so that you can satisfy all the requirements, meet the schedule, and produce a quality product. See Chapter for more details on process and software life cycles.
The ability to be flexible about that process : No project ever proceeds as you think it will on the first day. Requirements change, people come and go, tools dont work out or get updated, and so on. This point is all about handling risk in your project. If you identify risks, plan to mitigate them, and then have a contingency plan to address the event where the risk actually occurs, youll be in much better shape. Chapter talks about requirements and risk.
A plan that every one buys into : You wouldnt write a sorting program without an algorithm to start with, so you shouldnt launch a software development project without a plan. The project plan encapsulates what youre going to do to implement your project. It talks about process, risks, resources, tools, requirements management, estimates, schedules, configuration management, and delivery. It doesnt have to be long and it doesnt need to contain all the minute details of the everyday life of the project, but everyone on the team needs to have input into it, they need to understand it, and they need to agree with it. Unless everyone buys into the plan, youre doomed. See Chapter for more details on project plans.