software

{width=“598” height=“337” srcset=“tumblr_nk2ojojvBA1qz82meo1_1280.jpg 598w, tumblr_nk2ojojvBA1qz82meo1_1280-300x169.jpg 300w” sizes="(max-width: 598px) 100vw, 598px"} Nice illustration of the writing process, or any other creative/development endeavor, for that matter. Original Tweet: I love this illustration of this writing process. From Nicely Said book. pic.twitter.com/w5ccIVsrNX — ★ Sean Johnson (@seanuk) February 20, 2015 TODO: Link to the book source?

The problem? For example, 3 guys wrote a paper in 86 and they said that a good estimate is an estimate that’s within 25% of the original estimate, 75% of the time … so, mostly one quarter wrong . Yikes, not a very good prospect at all. The gist of #noestimates to determine how much scope can be delivered by a given date: Select the most important piece of work you need to do (highest value first) Break that piece of work down into risk-neutral chunks of work: (…) small enough that failing to deliver it at first attempt will not jeopardize the project [typically ~1 day chunks] Develop (…) Deliver that work to a production-like environment. Work is only done when it is ready to be used by real customers. Iterate and refactor : The first implementation can only reflect a first step in understanding what needs to be done. Be careful to let the system stabilize before it can provide reliable averages to predict the teams’ throughput. ...

Learn X in Y Minutes: Scenic Programming Language Tours Learn X in Y minutes : Take a whirlwind tour of your next favorite language. Community-driven!

The Flipboard Explorer, or FLEX, is a component that you can easily drop into any iOS project. When presented, FLEX shows a debugging toolbar that lives in a window above your app. From this toolbar, you can view and modify nearly every piece of state in the application. Unlike many other debugging tools, FLEX works entirely inside your app, so you donʼt need to be connected to LLDB/Xcode or a different remote debugging server. It works well in the simulator and on physical devices. ...

The Wilderness It’s a period of time where I’m pretty lost, and I don’t know what to do. I have feature lists, I have open bugs to fix, and I have an outline of where the app is going. But I feel mentally incapacitated, like I’m getting nothing done. I call this “The Wilderness”.

Not all technical debt is born the same, because A Mess is not a Technical Debt . (via TechnicalDebtQuadrant )

Compare and contrast different design artefacts (sketch, wireframe, mockup, and prototype) in terms of their fidelity, speed, cost and use cases.

(via What’s wrong with this picture? | Code.org ) Computer science is a top paying college degree and computer programming jobs are growing at 2x the national average . Less than 2.4% of college students graduate with a degree in computer science. And the numbers have dropped since last decade. See also Promote Computer Science | Code.org

Richard Feynman, the Challenger Disaster, and Software Engineering : Gustavo Duarte With respect to software, I take out four main points: Engineering can only be as good as its relationship with management Big design up front is foolish Software has much in common with other engineering disciplines Reliable systems are built by rigorously tested , incremental bottom-up engineering with an ‘attitude of highest quality’

Type-System Criteria · ongoing by Tim Bray Cri­te­ria Let’s call them the Bánffy-Bray cri­te­ria for se­lect­ing be­tween sta­tic and dy­namic type sys­tems. Sta­tic typ­ing’s at­trac­tive­ness is a di­rect func­tion (and dy­namic typ­ing’s an in­verse func­tion) of API sur­face size. Dy­namic typ­ing’s at­trac­tive­ness is a di­rect func­tion (and sta­tic typ­ing’s an in­verse func­tion) of unit test­ing work­a­bil­ity.

Bret Victor – Inventing on Principle (by CUSEC ) Their principles Elizabeth Cady Stanton — “Women should vote” Larry Tesler — “No person should be trapped in a mode” Doug Engelbart — “Enable mankind to solve solve the world’s urgent problems” (a vision of “knowledge workers” using complex powerful information tools to harness our collective intelligence) Alan Kay — “Amplify human reach and bring new ways of thinking into a faltering civilisation that desperately need it” ...

Creators need an immediate connection with what they’re making Bret Victor ’s guiding principle (via his talk Inventing on Principle )

What OO Fails to Do What object oriented programming fails to do is express collaborations between objects. To show you exactly what I mean, let’s take a look at two system operations (two use cases) requiring the same group of objects collaborating with each other. (…) DCI to the Rescue DCI is a paradigm invented by Trygve Reenskaug (the inventor of the MVC pattern) to solve these problems. (via Data Context Interaction: The Evolution of the Object Oriented Paradigm – SitePoint ) ...

Replacing The User Story With The Job Story We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ . For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them. See also 5 Tips For Writing A Job Story: ...

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago? Keep that in mind next time you want to cut a corner in your code. Rob Pike (via A lesson in shortcuts. Long ago, as the design of the Unix… )

The Twelve-Factor App 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 (…) Codebase Dependencies Config Backing Services Build, release, run Processes Port binding Concurrency Disposability Dev/prod parity Logs Admin processes

Mocks Aren’t Stubs Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (…) Meszaros then defined four particular kinds of double: Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example). Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’. Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive. The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn’t really matter that much. ...

Due to the interconnected, non-simple structure of ontologies, it’s difficult to give a simple diagram that fully models one. Instead, I’m just going to list the broad categories of classes that you find in an application and simply discuss how they actually interconnect. (via Cocoa with Love: The design of every Mac application ) See also, for a more practical view: What are the Xcode solution organisation best practices and guidelines? Code Organization in Xcode Projects

we-are-star-stuff: If you’re interested in an IT degree and career, coding can be pretty intimidating. From understanding common programming languages to deciphering programming from developing, learning to code is necessary in today’s IT industry. The ability to implement a variety of programming languages can help you decide which coding career path is correct for you. Additionally, comprehending multiple popular programming languages will make you more marketable in the IT industry at large. [via] ...

97 Things Every Programmer Should Know – Contributions Appearing in the Book Act with Prudence by Seb Rose Apply Functional Programming Principles by Edward Garson Ask “What Would the User Do?” (You Are not the User) by Giles Colborne Automate Your Coding Standard by Filip van Laenen Beauty Is in Simplicity by Jørn Ølmheim Before You Refactor by Rajith Attapattu Beware the Share by Udi Dahan The Boy Scout Rule by Uncle Bob Check Your Code First before Looking to Blame Others by Allan Kelly Choose Your Tools with Care by Giovanni Asproni Code in the Language of the Domain by Dan North Code Is Design by Ryan Brush Code Layout Matters by Steve Freeman Code Reviews by Mattias Karlsson Coding with Reason by Yechiel Kimchi A Comment on Comments by Cal Evans Comment Only What the Code Cannot Say by Kevlin Henney Continuous Learning by Clint Shank Convenience Is not an -ility by Gregor Hohpe Deploy Early and Often by Steve Berczuk Distinguish Business Exceptions from Technical by Dan Bergh Johnsson Do Lots of Deliberate Practice by Jon Jagger Domain-Specific Languages by Michael Hunger Don’t Be Afraid to Break Things by Mike Lewis Don’t Be Cute with Your Test Data by Rod Begbie Don’t Ignore that Error! by Pete Goodliffe Don’t Just Learn the Language, Understand its Culture by Anders Norås Don’t Nail Your Program into the Upright Position by Verity Stob Don’t Rely on “Magic Happens Here” by AlanGriffiths Don’t Repeat Yourself by Steve Smith Don’t Touch that Code! by Cal Evans Encapsulate Behavior, not Just State by Einar Landre Floating-point Numbers Aren’t Real by Chuck Allison Fulfill Your Ambitions with Open Source by Richard Monson-Haefel The Golden Rule of API Design by Michael Feathers The Guru Myth by Ryan Brush Hard Work Does not Pay Off by Olve Maudal How to Use a Bug Tracker by Matt Doar Improve Code by Removing It by Pete Goodliffe Install Me by Marcus Baker Inter-Process Communication Affects Application Response Time by Randy Stafford Keep the Build Clean by Johannes Brodwall Know How to Use Command-line Tools by Carroll Robinson Know Well More than Two Programming Languages by Russel Winder Know Your IDE by Heinz Kabutz Know Your Limits by Greg Colvin Know Your Next Commit by Dan Bergh Johnsson Large Interconnected Data Belongs to a Database by Diomidis Spinellis Learn Foreign Languages by Klaus Marquardt Learn to Estimate by Giovanni Asproni Learn to Say “Hello, World” by Thomas Guest Let Your Project Speak for Itself by Daniel Lindner The Linker Is not a Magical Program by Walter Bright The Longevity of Interim Solutions by Klaus Marquardt Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers Make the Invisible More Visible by Jon Jagger Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder A Message to the Future by Linda Rising Missing Opportunities for Polymorphism by Kirk Pepperdine News of the Weird: Testers Are Your Friends by Burk Hufnagel One Binary by Steve Freeman Only the Code Tells the Truth by Peter Sommerlad Own (and Refactor) the Build by Steve Berczuk Pair Program and Feel the Flow by Gudny Hauknes , Ann Katrin Gagnat , and Kari Røssland Prefer Domain-Specific Types to Primitive Types by Einar Landre Prevent Errors by Giles Colborne The Professional Programmer by Uncle Bob Put Everything Under Version Control by Diomidis Spinellis Put the Mouse Down and Step Away from the Keyboard by Burk Hufnagel Read Code by Karianne Berg Read the Humanities by Keith Braithwaite Reinvent the Wheel Often by Jason P Sage Resist the Temptation of the Singleton Pattern by Sam Saariste The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine Simplicity Comes from Reduction by Paul W. Homer The Single Responsibility Principle by Uncle Bob Start from Yes by Alex Miller Step Back and Automate, Automate, Automate by Cay Horstmann Take Advantage of Code Analysis Tools by Sarah Mount Test for Required Behavior, not Incidental Behavior by Kevlin Henney Test Precisely and Concretely by Kevlin Henney Test While You Sleep (and over Weekends) by Rajith Attapattu Testing Is the Engineering Rigor of Software Development by Neal Ford Thinking in States by Niclas Nilsson Two Heads Are Often Better than One by Adrian Wible Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly Ubuntu Coding for Your Friends by Aslam Khan The Unix Tools Are Your Friends by Diomidis Spinellis Use the Right Algorithm and Data Structure by JC van Winkel Verbose Logging Will Disturb Your Sleep by Johannes Brodwall WET Dilutes Performance Bottlenecks by Kirk Pepperdine When Programmers and Testers Collaborate by Janet Gregory Write Code as If You Had to Support It for the Rest of Your Life by Yuriy Zubarev Write Small Functions Using Examples by Keith Braithwaite Write Tests for People by Gerard Meszaros You Gotta Care about the Code by Pete Goodliffe Your Customers Do not Mean What They Say by Nate Jackson \