Tag: programming
Frequently Forgotten Fundamental Facts about Software Engineering
by Steve Hernandez on Dec.02, 2009, under Academic, Technology

Robert L. Glass
This month’s column is simply a collection of what I consider to be facts—truths, if you will—about software engineering. I’m presenting this software engineering laundry list because far too many people who call themselves software engineers, or computer scientists, or programmers, or whatever nom du jour you prefer, either aren’t familiar with these facts or have forgotten them.
I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination! Enough preliminaries. Here are the most frequently forgotten fundamental facts about software engineering. Some are of vital importance—we forget them at considerable risk.
Complexity
C1. For every 10-percent increase in problem complexity, there is a 100-percent increase in the software solution�s complexity. That’s not a condition to try to change (even though reducing complexity is always desirable); that’s just the way it is. (For one explanation of why this is so, see RD2 in the section “Requirements and design.”)
People
P1. The most important factor in attacking complexity is not the tools and techniques that programmers use but rather the quality of the programmers themselves.
P2. Good programmers are up to 30 times better than mediocre programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
Tools and techniques
T1. Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. But at one time or another, most of these improvements have been claimed by someone to have “order of magnitude” (factor of 10) benefits. Hype is the plague on the house of software.
T2. Learning a new tool or technique actually lowers programmer productivity and product quality initially. You achieve the eventual benefit only after overcoming this learning curve.
T3. Therefore, adopting new tools and techniques is worthwhile, but only if you (a) realistically view their value and (b) use patience in measuring their benefits.
Quality
Q1. Quality is a collection of attributes. Various people define those attributes differently, but a commonly accepted collection is portability, reliability, efficiency, human engineering, testability, understandability, and modifiability.
Q2. Quality is not the same as satisfying users, meeting requirements, or meeting cost and schedule targets. However, all these things have an interesting relationship: User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost.
Q3. Because quality is not simply reliability, it is about much more than software defects.
Q4. Trying to improve one quality attribute often degrades another. For example, attempts to improve efficiency often degrade modifiability.
Reliability
RE1. Error detection and removal accounts for roughly 40 percent of development costs. Thus it is the most important phase of the development life cycle.
RE2. There are certain kinds of software errors that most programmers make frequently. These include off-by-one indexing, definition or reference inconsistency, and omitting deep design details. That is why, for example, N-version programming, which attempts to create multiple diverse solutions through multiple programmers, can never completely achieve its promise.
RE3. Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Automated support, such as coverage analyzers, can raise that to roughly 85 to 90 percent. Testing at the 100-percent level is nearly impossible.
RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!).
RE5. There is no single best approach to software error removal. A combination of several approaches, such as inspections and several kinds of testing and fault tolerance, is necessary.
RE6. (corollary to RE5) Software will always contain residual defects, after even the most rigorous error removal. The goal is to minimize the number and especially the severity of those defects.
Efficiency
EF1. Efficiency is more often a matter of good design than of good coding. So, if a project requires efficiency, efficiency must be considered early in the life cycle.
EF2. High-order language (HOL) code, with appropriate compiler optimizations, can be made about 90 percent as efficient as the comparable assembler code. But that statement is highly task dependent; some tasks are much harder than others to code efficiently in HOL.
EF3. There are trade-offs between size and time optimization. Often, improving one degrades the other.
Maintenance
M1. Quality and maintenance have an interesting relationship (see Q3 and Q4).
M2. Maintenance typically consumes about 40 to 80 percent (60 percent average) of software costs. Therefore, it is probably the most important life cycle phase.
M3. Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not about fixing it.
M4. The previous two facts constitute what you could call the “60/60″ rule of software.
M5. Most software development tasks and software maintenance tasks are the same—except for the additional maintenance task of “understanding the existing product.” This task is the dominant maintenance activity, consuming roughly 30 percent of maintenance time. So, you could claim that maintenance is more difficult than development.
Requirements and design
RD1. One of the two most common causes of runaway projects is unstable requirements. (For the other, see ES1.)
RD2. When a project moves from requirements to design, the solution process’s complexity causes an explosion of “derived requirements.” The list of requirements for the design phase is often 50 times longer than the list of original requirements.
RD3. This requirements explosion is partly why it is difficult to implement requirements traceability (tracing the original requirements through the artifacts of the succeeding lifecycle phases), even though everyone agrees this is desirable.
RD4. A software problem seldom has one best design solution. (Bill Curtis has said that in a room full of expert software designers, if any two agree, that’s a majority!) That’s why, for example, trying to provide reusable design solutions has so long resisted significant progress.
Reviews and inspections
RI1. Rigorous reviews commonly remove up to 90 percent of errors from a software product before the first test case is run. (Many research findings support this; of course, it’s extremely difficult to know when you’ve found 100 percent of a software product’s errors!)
RI2. Rigorous reviews are more effective, and more cost effective, than any other error-removal strategy, including testing. But they cannot and should not replace testing (see RE5).
RI3. Rigorous reviews are extremely challenging to do well, and most organizations do not do them, at least not for 100 percent of their software artifacts.
RI4. Post-delivery reviews are generally acknowledged to be important, both for determining customer satisfaction and for process improvement, but most organizations do not perform them. By the time such reviews should be held (three to 12 months after delivery), potential review participants have generally scattered to other projects.
Reuse
REU1. Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
REU2. Reuse-in-the-large (components) remains largely unsolved, even though everyone agrees it is important and desirable.
REU3. Disagreement exists about why reuse-in-the-large is unsolved, although most agree that it is a management, not technology, problem (will, not skill). (Others say that finding sufficiently common subproblems across programming tasks is difficult. This would make reuse-in-the-large a problem inherent in the nature of software and the problems it solves, and thus relatively unsolvable).
REU4. Reuse-in-the-large works best in families of related systems, and thus is domain dependent. This narrows its potential applicability.
REU5. Pattern reuse is one solution to the problems inherent in code reuse.
Estimation
ES1. One of the two most common causes of runaway projects is optimistic estimation. (For the other, see RD1.)
ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.
ES3. Most software estimates are made, according to several researchers, by either upper management or marketing, not by the people who will build the software or by their managers. Therefore, the wrong people are doing estimation.
ES4. Software estimates are rarely adjusted as the project proceeds. So, those estimates done at the wrong time by the wrong people are usually not corrected.
ES5. Because estimates are so faulty, there is little reason to be concerned when software projects do not meet cost or schedule targets. But everyone is concerned anyway!
ES6. In one study of a project that failed to meet its estimates, the management saw the project as a failure, but the technical participants saw it as the most successful project they had ever worked on! This illustrates the disconnect regarding the role of estimation, and project success, between management and technologists. Given the previous facts, that is hardly surprising.
ES7. Pressure to achieve estimation targets is common and tends to cause programmers to skip good software process. This constitutes an absurd result done for an absurd reason.
Research
RES1. Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth less than their advocates believe and (b) there is a shortage of evaluative research to help determine the actual value of new tools and techniques.
There, that’s my two cents’ worth of software engineering fundamental facts. What are yours? I expect, if we can get a dialog going here, that there are a lot of similar facts that I have forgotten—or am not aware of. I’m especially eager to hear what additional facts you can contribute.
And, of course, I realize that some will disagree (perhaps even violently!) with some of the facts I’ve presented. I want to hear about that as well.
Robert L. Glass is the editor of Elsevier’s Journal of Systems and Software and the publisher and editor of The Software Practitioner newsletter. Contact him at rglass@indiana (dot) education; he’d be pleased to hear from you.
Reprinted from IEEE Software, vol. 18, no. 3, 2001, pp. 112, 110–111.
Professional IT Consulting
by Steve Hernandez on May.19, 2008, under Technology
I have been an IT consultant for the past 5 years and in the industry for almost 10. My experience is vast and covers both hardware and software aspects of corporate and personal IT needs (click here for professional experience). My company, The Tech Guy, offers an extensive list of services, ranging from Web Development and Design, to emergency Data Recovery, network and system support, etc.
Below is concise list of the services we currently offer. If there’s something you need that is not on the list, please contact me (contact me anyway!) so that we can talk about it. Our services are affordable (cheap but of high quality) and we make a huge effort to fit in any budget.
Services:
- Web Development
- Application Programming
- Application Support
- Application updates and upgrading (Web and System level software)
- Software Installations
- Web Design
- Web Layouts
- Web Design: FLASH
- Web Design: Dynamic and static sites
- eCommerce – Shopping cart front and back-ends
- Club and Organization websites
- Affordable Non-Profit websites
- Network Support
- Network Installation
- Network Upgrade
- Network Device Installation and Support
- Computer Maintenance
- Computer Upgrade
- Computer Installation
- Computer Repair
- Data Recovery
- Hard Drive Failure: File and Data Recovery
- Hard Drive Format: File and Data Recovery
- Emergency Computer and Network Services
- Remote Support (anywhere in the world!)
- Virus Removal
- Spyware Removal
- Adware Removal
- Trojan and other Malware Removal
- Software Sales
- Hardware Sales
- New and Used equipment sales and installation
- Repair and Maintenance plans
- Full IT Outsourcing (We can be your IT department at less than 25% of the cost!)
- Blog Website Installations
- Joomla Websites
- Joomla Design
- Joomla Custom Applications
- Website Hosting
- Website Maintenance and Updating
- Image and Multimedia Editing
- Image Manipulation
- Digital Archiving
- Flyer Design
- Event Poster Design and Printing
- Flyer Printing
- Business Cards (Affordable!) Design
- Business Card Printing
- Pamphlet and Booklet Design and Printing
- Car Magnet Printing and Design
- Photography Services
- Business Services
- Marketing Services
- Full marketing campaign management
- Google Ads
- Yahoo Ads
- Microsoft Live Ads
- Search Engine Ads
- Search Engine Optimization (SEO) for new and existing sites
- Reporting and progress reports
All services provided by The Tech Guy, Changing the way you see IT, and are offered to Individuals and Business alike.
Professional Resume of Steve Hernandez
by Steve Hernandez on Mar.30, 2008, under Uncategorized
|
Steve O Hernandez .: Professional Resume :.
My Current Resume – Plain PDF version of my resume skills and experience
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Great homework question
by Steve Hernandez on Jul.24, 2007, under Academic
Here is one of the questions from my Programming Languages homework which took me a bit of thinking to figure out. The answer, is of course, surprisingly simple and straightforward (as most correct answers are). I hope this helps someone. Don’t cheat, make sure it makes sense to you before just copying it.
Q: Write a grammar for the language consisting of strings that have n copies of the letter a followed by the same number of copies of the letter b, where n > 0. For example, the strings ab, aaaabbbb, and aaaaaaaabbbbbbbb are in language but a, abb, ba, and aaabb are not.
A:
<S> -> <A>
<A> -> a<A><B> | a<B>
<B> -> b
Proof:
aaaabbbb
<S> -> <A>
-> a<A><B>
-> aa<A><B><B>
-> aaa<A><B><B><B>
-> aaaa<B><B><B><B>
-> aaaab<B><B><B>
-> aaaabb<B><B>
-> aaaabbb<B>
-> aaaabbbb
aaabb
<S> -> <A>
-> a<A><B>
-> aa<A><B><B>
X -> aaa<A><B><B><B> OR aaa<B><B><B>
Edit: 7.27.2007
So the simpliest correct answer is:
<S> -> a<S>b | ab
NiCE! It seems I over complicate even the easiest things
My next certification
by Steve Hernandez on Jun.26, 2007, under Projects
I’m currently on the track to earn two masters degrees (Information Security and Computer Science) and a doctorate in Computer Science. Well, I’ve decided that I would like to earn a certification as well. There are a few reasons for my choice, but the main reasons are 1) programming is my passion, 2) I have web programming experience and would like to validate it with a certification, 3) the potential work oppurtunities will increase with the certification, and 4) I chose this certification as opposed to an MCSA or MCSE because it only requires 2 exams and because I feel that the experiences I already have can validate my Network Administrator experience.
The certification is the Microsoft Certified Technology Specialist (MCTS), particularly the MCTS: .NET Framework 2.0 Web Applications using VB.NET. My initial goal was to earn it within 6 months from today as I continue my traditional education, however, since the books I purchased won’t be here until the end of August and the other at the end of December. The two books I ordered from Amazon are the much awaited books byAmit Kalani.
“MCTS 70-536 Exam Prep: Microsoft .NET Framework 2.0 Foundation Exam (Exam Cram 2)”
Amit Kalani; Hardcover; $40.79
“MCTS 70-528 Exam Prep: Microsoft .NET Framework 2.0 Web-based Client Development Exam (Exam Cram 2)”
Amit Kalani; Paperback; $40.79
So my goal has evolved to 6 months from the reciept of the first book should be arriving at the end of August, and at 3 months per exam that gives me from Sept – Nov for the first and Dec – Feb for the second, all while I continue schooling.
This will be interesting… I will keep you updated!
Certifications vs. Degree
by Steve Hernandez on Feb.26, 2007, under Technology
In the age where most of society has to make a living (including me; I started working when I was 13) I continously find myself in the conversation of whether someone in the IT field should go for their certs or go to school. This especially became the issue while I worked as a teacher at a certifcation ’school’ (and I use that term loosely), where my students expected the world upon graduation, only to find out that they simply moved up a notch on a very long ladder.
I once read in a magazine about 4 years ago “An MCSE without experience is like having a submarine with screen doors”, and to this day I think it’s brillant. It encapsulates the idea that, either way, experience rules above all else (when it comes to getting a job, not advancing, which is a totally different story all together.
To get a job, I say get the Certifications. Why? Because they train you in a specific task on a specific software set on a particular system (say, an MCP in Windows XP). You become a specialized robot, and therefore, are perfect for a specific task. I said task, not tasks, because again you’re a working robot, not someone who can readily advance into management (unless you have tons of experience and/or tons of certs [ie. knowledge]).
To get a career, definitely get the degree. Why? Because degrees don’t expire. The market for an MCSE in NT Server is dwindling and long overdue for a certification upgrade. Not so for a Bachelors in Computer Science. The assumption that comes with the degree is the ability to learn new things, to critically think, problem solve, and to understand the inner workings of computer systems, programming, computer architecture, etc. I, having experience in management, would more readily give new and challenging tasks to my college graduate, than to my cert holding employees. When was the last time you saw a robot learn something without having to be manually programmed?
So the market for IT professionals with certs is huge, and degrees equally competative. How do you get ahead? Either you get really lucky, have a good resume and do awesome at your interview. Or you know someone who’s in the industry already and has some pull, or you know the boss and get an entry level position. Or, you blow them all out of the water and you show your resume with certifications and degrees (and if you have less experience, you accept a lower pay than expected to build your resume, because of course, experience is king [I can't tell you how many times I've seen IT directors and managers with no degree, no cert, but with 10 years experience in the same position with the same company]).
In summation, the answer to the question all depends on what you want to do. Certs are great for people who are looking for a career change, but at the end of the day I would have to say that a degree is worth it’s weight in gold, many times over.
Added: Not exactly on the same subject, but an interesting read.