Skip to main content

Home/ Coders/ Group items tagged engineering

Rss Feed Group items tagged

Fabien Cadet

[video] InfoQ: Development at the Speed and Scale of Google, 2010-12-13 by Ashish Kumar - 4 views

  •  
    « Ashish Kumar presents how Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository. »
Fabien Cadet

Why writing software is not like engineering. by Terence Parr - 5 views

  • ...30% of all software projects are canceled, nearly half come in over budget, 60% are considered failures by the organizations that initiated them, and 9 out of 10 come in late.
  • Unfortunately, midcourse design changes happen in software all the time
  • In fact, the agile software development method is a direct response to ever-changing design requirements.
  • ...2 more annotations...
  • Still, constant changes to the design hamper development efforts and developers must constantly refactor software to prevent it from becoming a tangled, unmaintainable mess.
  • If you look at software today, through the lens of the history of engineering, it's certainly engineering of a sort--but it's the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Fabien Cadet

Software Engineering: Dead? @ Coding Horror - 0 views

  • The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed.
  • Everything else is just noise.
  • If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.
  •  
    « I'm gradually coming to the conclusion that software engineering is an idea whose time has come and gone. Software development is and always will be somewhat experimental. The actual software construction isn't necessarily experimental, but its conception is. And this is where our focus ought to be. It's where our focus always ought to have been. » __ Tom DeMarco
Fabien Cadet

Sonar : Code quality management platform - 0 views

  •  
    "Sonar enables to collect, analyze and report metrics on source code. Sonar not only offers consolidated reporting on and across projects throughout time, but it becomes the central place to manage code quality."
Kevin O'Neill

The 7 Software "-ilities" You Need To Know - 0 views

  • 1. Usability Software usability can be described as how effectively end users can use, learn, or control the system
  • 2. Maintainability ( or Flexibility / Testibility) The definition of maintainability [for me] implies how brittle the code is to change
  • 3. Scalability Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage
  • ...4 more annotations...
  • 4. Availability (or Reliability) How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program
  • 5. Extensibility Are there points in the system where changes can be made with (or without) program changes?
  • 6. Security I shouldn’t need to go into this one but to be thorough I like this definition of security: the measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.
  • 7. Portability Portability is the ability for your application to run on numerous platforms.
Kevin O'Neill

In Search of Excellent Requirements - 1 views

  • Consequently, it is not reasonable to expect us to make sound business or technical decisions on behalf of the customers, or to resolve conflicting requirements supplied by different end users, or to set priorities for the many requirements that might be collected.
  • We have finally reached the state where if no project champion can be found to see that the right system is built, we cancel the project.
  • The consequence of not explicitly discussing these quality tradeoffs is a surprise upon delivery, when the customer finds that his implicit quality attribute requirements have not been achieved
  • ...3 more annotations...
  • One way to reach an appropriate middle ground in the specification process is to conduct formal inspections of the SRS. A structured document like the IEEE SRS is readily inspected by the design team, the project champions, other representative users, and other software engineers who are not directly involved with the project
    • Kevin O'Neill
       
      sadly, this is something that is always left to the end to 'clean up'. Meaning, the spec is complete when the project is delivered versus kept up to date and in sync with what we are delivering.
  • A prototype is intended to answer specific questions about functionality or interaction styles. If you don't have any questions, don't bother with a prototype
  • Even in a small software group, a focus on accurately and completely capturing, documenting, and modeling the user requirements is a major contributor to building high quality information systems
1 - 13 of 13
Showing 20 items per page