Posted by jpluimers on 2019/09/09
Interesting point of view: [WayBack] Jim Rohn: You’re The Average Of The Five People You Spend The Most Time With – Business Insider
From quite a while ago, via [WayBack] Select your friends and working partners wisely! “You are the average of the 5 people you spend the most time with.” – Jim Rohn – Marjan Venema – Google+
–jeroen
Posted in Agile, Development, LifeHacker, Power User, Software Development | Leave a Comment »
Posted by jpluimers on 2019/09/09
Food for thought:
Let’s put aside frameworks for the moment and focus on the principles of scaling any agile approach. Why should we scale? When?
TL;DR
Source: [WayBack] Two Principles for Scaling Any Agile Approach – Spikes And Stories
Via [WayBack] Two Principles for Scaling Any Agile Approach – Spikes And Stories – Marjan Venema – Google+
–jeroen
Posted in Agile, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2019/08/29
via [WayBack] Writing solid code the NASA way. – Lars Fosdal – Google+, I bumped into [WayBack] How To Code Like The Top Programmers At NASA — 10 Critical Rules:
Do you know how top programmers write mission-critical code at NASA? To make such code clearer, safer, and easier to understand, NASA’s Jet Propulsion Laboratory has laid 10 rules for developing software.
The rules:
- Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
- All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
- Do not use dynamic memory allocation after initialization.
- No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
- The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).
- Data objects must be declared at the smallest possible level of scope.
- The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
- The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.
- The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
- All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.
–jeroen
PS: twitter comment
“All code must compile with these settings without any warnings” – I absolutely agree with this. It really annoys me to find code which people have shipped which generates warnings. They’re there for a reason and should be fixed! 👍
Posted in Agile, Code Quality, Conference Topics, Conferences, Development, Event, Software Development | Leave a Comment »
Posted by jpluimers on 2019/08/28
Must watch when you do unit testing (no matter the environment): [WayBack] Structure and Interpretation of Test Cases : Kevlin Henney on Vimeo which he presented at Javazone 2018 [Archive.is]
via [WayBack] Kevlin Henney – Google+
–jeroen
Posted in Agile, Conference Topics, Conferences, Development, Event, Software Development, Unit Testing | Leave a Comment »
Posted by jpluimers on 2019/07/10
I think the alt-text is even better than the cartoon itself:
I started off with countless problems. But now I know, thanks to COUNT(), that I have “#REF! ERROR: Circular dependency detected” problems.
Source: [WayBack] XKCD 1906: I started the day with lots of problems. But now, after hours and hours of work, I have lots of problems in a spreadsheet.
–jeroen
Posted in Agile, Development, Fun, Quotes, Software Development | Leave a Comment »
Posted by jpluimers on 2019/06/26
Definitely worth reading when you think you’re being Agile, but you don’t. [WayBack] Why Isn’t Agile Working? – Hacker Noon.
Via:
–jeroen
Posted in Agile, Development, Software Development | 1 Comment »
Posted by jpluimers on 2019/06/11
The sad thing is that most security people do not like these kinds of user stories:
As any user, I never want to get a “denied” message, but a “in order to do what you want you are missing the X permission” message in order to be able to track down the root cause and request the appropriate permissions more easily.
Source: [WayBack] A (sad) security user story – The Isoblog.
Related: [WayBack] User Stories and User Story Examples by Mike Cohn
–jeroen
Via: [WayBack] A (sad) security user story… – Kristian Köhntopp – Google+
Posted in Agile, Development, Scrum, Software Development | Leave a Comment »
Posted by jpluimers on 2019/06/06
A few nice reads on that not to estimate and why:
Related:
Via:
–jeroen
Posted in Agile, Development, Scrum, Software Development | Leave a Comment »
Posted by jpluimers on 2019/06/04
Should be on the wall for every development team around:
Why We Write Tickets
Shared with my team the other day in Slack …
Why we write tickets
- So if we get sick, a teammate can help us out
- To help us decompose our work into small pieces
- As a placeholder for a real-life conversation
- To keep track of how we resolved the issue
- To make our standups effective
- To point out dependencies
- To reflect on the mix/makeup of our work during retros
- Self-discipline.
- Don’t take on too much.
- Try to do one thing at a time
Why we DON’T write tickets
- To track our time
- To compete with other team members
- To show managers we’re busy
- To make managing people possible
- To report status, or % complete
- Because Jira is fun to use
- External discipline
John CutlerFollow – Multiple hat-wearer. Product development nut. I love wrangling complex problems and answering the why with qual/quant data. May 4
Source: [WayBack] Why We Write Tickets – Hacker Noon
Via: [WayBack] Why We Write Tickets – Hacker Noon – Marjan Venema – Google+
–jeroen
Posted in Agile, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2019/05/28
Recommended read: [WayBack] Clean Code is a team sport! – writeabout.net.
The picture is of a developer journey taking years to go from fresh to seasoned ending up at exactly the same code: over time learning the sweet spot of coding.
The story continues correlating that journey to handling technical debt and finding the sweet spot between that and business value.
via:
–jeroen
Posted in Agile, Code Quality, Code Review, Development, Software Development | Leave a Comment »
The Wiert Corner - irregular stream of stuff 