Scroll down
There are no secrets on an successful software project. Both good and bad news must be able to move up and down the ptoject hierarchy without restriction.
Software Project Survival Guide by Steve C McConnell
ISBN: 1572316217 Page: 93 This book is available from Amazon
The job of the average manager requires a shift in focus every few minutes. The job of the average software developer requires that the developer not shift focus more often than every few hours.
ISBN: 1572316217 Page: 45 This book is available from Amazon
It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it.
Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better.
Code Complete: A Practical Handbook of Software Construction by Steve C McConnell
ISBN: 1556154844 This book is available from Amazon
Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer.
A brute force solution that works is better than an elegant solution that doesn't work.
It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error-free.
Some programming practices beg for errors; this one is like calling an 800 number and having errors delivered to your door.
Good visual layout shows the logical structure of a program.
ISBN: 1556154844 Page: 403 This book is available from Amazon
The visual and intellectual enjoyment of well-formatted code is a pleasure that few nonprogrammers can appreciate. But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code.
ISBN: 1556154844 Page: 399 This book is available from Amazon
Large projects call for organizational practices that formalize and streamline communication. ...All the ways to streamline communication rely on creating some kind of hierarchy, that is, creating small groups, which function as teams, and then appointing representatives from those groups to interact with each other and with management.
Rapid Development: Taming Wild Software Schedules by Steve C McConnell
ISBN: 1556159005 This book is available from Amazon
Feature teams have the advantages of empowerment, accountability, and balance. The team can sensibly be empowered because it contains representatives ...from each of the concerned parties. The team will consider all necessary viewpoints in its decisions and thus there will hardly ever be a basis for overriding it decisions. For the same reason, the team becomes accountable. They have access to all the people they need to make good decisions. If they don’t make good decisions, they have no one to blame but themselves. The team is balanced. You wouldn’t want development, marketing, or quality assurance alone to have ultimate say over a product’s specification, but you can get balanced decisions from a group that includes representatives from each of those categories.
Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation.
Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively.
ISBN: 1572316217 This book is available from Amazon
In software, the chain isn't as strong as its weakest link; it's as weak as all the weak links multiplied together
from Code Complete
Tools are very important element of defining a path of least resistance. If I can set up a tool so that it’s easier for a developer to do something the way that I want the developer to do it, and harder for the developer to do it some other way, then I think it’s very likely the developer is going to do it the way I want them to, because it’s easier. It’s the path of least resistance.
The problem with quick and dirty...is that dirty remains long after quick has been forgotten.
As Thomas Hobbes observed in the 17th century, life under mob rule is solitary, poor, nasty, brutish, and short. Life on a poorly run software project is solitary, poor, nasty, brutish, and hardly ever short enough.
ISBN: 1572316217 Page: 7, Chapter 1 This book is available from Amazon
Early in the project you can have firm cost and schedule targets or a firm feature set, but not both.
ISBN: 1572316217 Page: 33, Chapter 3 This book is available from Amazon
It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.
ISBN: 1572316217 Page: 103, Chapter 7 This book is available from Amazon
The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory, developmental activity of helping users figure out what they want.
ISBN: 1572316217 Page: 114, Chapter 8 This book is available from Amazon
The problem with quick and dirty, as some people have said, is that the dirty remains long after the quick has been forgotten.
ISBN: 1572316217 Page: 127, Chapter 9 This book is available from Amazon
Seymour Cray, the designer of the Cray supercomputers, says that he does not attempt to exceed engineering limits in more than two areas at a time because the risk of failure is too high. Many software projects could learn a lesson from Cray. If your project strains the limits of computer science by requiring the creation of new algorithms or new computing practices, you're not doing software development, you're doing software research.
One of the most effective guidelines is not to get stuck on a single approach. If writing the program in PDL isn't working, make a picture. Write it in English. Write a short test program. Try a completely different approach. Think of a brute-force solution. Keep outlining and sketching with your pencil, and your brain will follow. If all else fails, walk away from the problem. Literally go for a walk, or think about something else before returning to the problem. If you've given it your best and are getting nowhere, putting it out of your mind for a time often produces results more quickly than sheer persistence can.
Horst Rittel and Melvin Webber defined a 'wicked' problem as one that could be clearly defined only by solving it, or by solving part of it. This paradox implies essentially, that have to 'solve' the problem once in order to clearly define it and then solve it again to create a solution that works. This process is almost motherhood and apple pie in software development.
The source code is often the only accurate description of the software. On many projects, the only documentation available to programmers is the code itself. Requirements specifications and design documents can go out of date, but the source code is always up to date. Consequently, it's imperative that the code be of the highest possible quality.
It's time for software development to grow up.
After the Gold Rush : Creating a True Profession of Software Engineering (Best Practices) by Steve C McConnell
ISBN: 0735608776 This book is available from Amazon
Computer programs are complex by nature. Even if you could invent a programming language that operated exactly at the level of the problem domain, programming would be complicated because you would still need to precisely define relationships between real-world entities, identify exception cases, anticipate all possible state transitions, and so on. Strip away the accidental work involved in representing these factors in a specific programming language and in a specific computing environment, and you still have the essential difficulty of defining the underlying real-world concepts and debugging your understanding of them.
ISBN: 0735608776 Page: 81 This book is available from Amazon
"If it ain't broke, don't fix it," the saying goes. Common software development practices are seriously broken, and the cost of not fixing them has become extreme. Traditional thinking would have it that the change represents the greatest risk. In software's case, the greatest risk lies with not changing - staying mired in unhealthy, profligate development practices instead of switching to practices that were proven more effective many years ago.
ISBN: 0735608776 Page: xiii This book is available from Amazon
A final essential difficulty arises from software's inherent invisibility. Software can't be visualized with 2-D or 3-D geometric models. Attempts to visually represent even simple logic quickly becomes absurdly complicated, as anyone who has ever tried to draw a flow chart for even a simple program will attest.
Managers of programming projects aren’t always aware that certain programming issues are matters of religion. If you’re a manager and you try to require compliance with certain programming practices, you’re inviting your programmers’ ire. Here’s a list of religious issues: ■ Programming language ■ Indentation style ■ Placing of braces ■ Choice of IDE ■ Commenting style ■ Efficiency vs. readability tradeoffs ■ Choice of methodology—for example, Scrum vs. Extreme Programming vs. evolutionary delivery ■ Programming utilities ■ Naming conventions ■ Use of gotos ■ Use of global variables ■ Measurements, especially productivity measures such as lines of code per day.
