Group items tagged

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: - Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; - Have a clean contract with the underlying operating system, offering maximum portability between execution environments; - Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; - Minimize divergence between development and production, enabling continuous deployment for maximum agility; - And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

In this article, author talks about how to improve the accuracy of software development effort estimations. He suggests to use relevant historical data improve estimation accuracy and to avoid early estimates based on incomplete information. He also discusses how to measure and predict productivity in software projects.

A few years ago, I took on a freelance project to implement an Internet Explorer component in C++. I was billing a healthy hourly rate on other projects at the time, but this particular client insisted on a fixed price. In a bout of temporary insanity, I made an exception.... Every developer knows that accurate software estimation is not possible even when perfect information is available about project requirements (i.e. practically never).....

podobne nazory na estimate trvania taskov som cez vikend cital aj v tomto clanku https://techcrunch.com/2016/12/11/death-to-jira/ , odhady veru nie su easy

Z toho clanku "death to JIRA" vypichujem: For some reason many companies today seem to be terrified of the prospect of writing more than a couple of paragraphs of clear and simple prose. But a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets. ... Feature planning is about communication. JIRA is fundamentally a terrible way to communicate the requirements of a complex system. Words in a row, if written well, will always be better. A v dost vela veciach suhlasim.

the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.

Cognitive dissonance is the most often cited reason for claims for independent testing teams. IF the tester is part of the development team that created the product, then he will be biased to confirm the product is working.

paradny writeup use caseov, kedy je vhodne pouzit sqlite DB

narazil som na toto hodinove video, a napriek tomu ze neznasam videa, toto povazujem za velmi prinosne. pre mna to je zhrnutie pocitov a nazorov ktore som intuitivne "tusil", ale v tom videu ich ten chlapik povie nahlas a je to pekne explicitne vyslovene a presvedcive.

Linux servers displayed a notable tendency to misbehave during the leap second event at the end of the day on June 30. The problem often presented itself as abrupt and sustained load spikes on the affected machines....a look at what happened shines an interesting light on the trickiness of dealing with time in software systems.

It all sounds so straightforward: Put your code up on GitHub or start/join a project at the Apache Software Foundation (ASF), build a community of like-minded individuals, start a company, take in some funding, and then IPO. Or maybe not. One thing is certain: Running an open source company has unique challenges and opportunities.

Making everything easy to change makes the entire system very complex. Technical debt is a metaphor developed by Ward Cunningham, who uses the term to describe the design tradeoffs we make in order to meet schedules and customer expectations.

It's not useful to reserve a portion of my screen for displaying which applications are running, as the things that are running are visible and the things that aren't visible can be found when necessary. There's no need for an icon displaying wifi status; if I'm connected it's uninteresting and if I'm not connected I'll surely discover it if I attempt to use the internet.

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Workplace stress costs the U.S economy hundreds of billions of dollars per year and is prevalent across all types of organizations and workplaces. If you have adopted or are in the process of adopting the devops methodology and culture, chances are your software developers are burning out as well.