Software Development

Home /
Tags /
Software Development

The Hacker Way

A few days ago, Paweł Wrzeszcz sent me Erik Meijer’s talk “One Hacker Way” (watch here) from the GOTO Conference in Copenhagen. It is a very provocative talk, which is great. It questions the Scrum method and challenges the status quo in Agile. Given that Scrum is a dominant framework in software development, a critical view is healthy, especially as Agile has become a significant business machine over the past 20 years. When implementing Agile at Scale, core ideas can easily become distorted. (Check out Dave Thomas’ “Agile is Dead” talk here).

Natural Course of Refactoring online on InfoQ

I am so delighted that the article about Natural Course of Refactoring is live. It is a very simple, yet powerful idea about refactoring (but not easy after all) and I hope this way it will reach more people than ever before. So please retweet it and share it wherever you can.

...and What If You Are Just a Small Planet at the Edge of the Milky Way

I recently had a conversation with my colleague about the importance of having a domain expert available in a project to clarify domain-specific questions.

Building Knowledge in a Team: Main Mistakes and Strategies

Introduction

For IT leaders, the topic of knowledge management is often unexplored territory. There is a silent assumption that it happens on its own. While it’s true to some extent, as software developers, we constantly need to learn new things to stay relevant. However, it’s not enough if only some team members learn independently. For a team to work efficiently, they need consistent and up-to-date knowledge. Cutting-edge technology skills alone have limited value.

Simple, Complicated, Complex and Chaotic Systems, in Other Words Cynefin. And How Does It Relate to Software Development?

Intro

You might have already come across terms such as complex systems, complicated systems, or complex adaptive systems; especially, if you have read Management 3.0 by Jurgen Appelo or heard about Ken Schwaber’s ideas about the applicability of Scrum. It might sound intriguing, but finding logic in it is difficult without some background theory. This is the point at which Dave Snowden’s Cynefin concept comes in handy. This concept is based on complex systems theory, anthropology, evolutionary psychology, and, last but not least, cognitive psychology.

Simple, Complicated, Complex, and Chaotic Systems: The Cynefin Framework

Perhaps you’ve previously encountered concepts such as complex systems, complicated systems, or complex adaptive systems, for instance when reading Jurgen Appelo’s Management 3.0, or when considering Ken Schwaber’s thoughts on the applicability of Scrum. This might sound intriguing, but it can be difficult to find logical sense in it if one lacks a certain theoretical foundation. This is where it’s worthwhile to examine Dave Snowden’s concept called Cynefin, which is based on complex systems theory, anthropology, evolutionary psychology, and cognitive psychology.

A Morning Thought: The Greatest Contribution of Agile

A Morning Thought: The Greatest Contribution of Agile

Today morning I came across Henrik Kniberg’s video http://www.youtube.com/watch?v=Rb0O0Lgs9zU titled Culture over Process. What hit me was that it was about Culture.

Architectural Mantra

Those who attended JDD 2013 could see it live. For those who weren’t there or missed it, below you will find a presentation on the Architectural Mantra along with an extensive article. Set aside some time for this.

Truth Does Not Exist (Proofs Neither)

Since my response to Sławek’s post has grown quite lengthy, I decided to also publish it here. Please read his post first, as my commentary only makes sense in its context.

Where Is It Worth Getting Employed?

The Idea Behind

For quite some time now, I have been my own employer, so I am not actively looking for traditional employment. However, people I meet during various projects and trainings often ask where it is worth getting employed.

Master... Master...

The Role of the Scrum Master

In the real world, there are many variations of this role. Sometimes it’s a person from the team, sometimes a manager, sometimes someone from outside the team, sometimes a specialist in being a Scrum Master, and I’ve even seen it as a rotating role within the team. So, who is it really? What’s the purpose?

Estimation Is Not a Commitment

Estimation Is Not a Commitment

You’ve probably heard that estimation is not a commitment. Sometimes in teams using estimation techniques, some form of accountability for the accuracy of estimation emerges. This is unfavorable for several reasons:
a) firstly, estimation is an approximation (with some probability), not a definitive result;
b) secondly, when accountability kicks in, project games emerge;
c) there are at least several factors causing estimation to differ from the actual time spent on a given task:

The Six Deadly Sins of Technical Leaders

Introduction

I probably would not have written this post if Michał hadn’t encouraged me. Over the past few months, I’ve slowly come to terms with a realization that I was hesitant to accept, yet it is quite understandable.

Don't Be Too Quick, Start Thinking!

Don’t Be Too Quick, Start Thinking!

Sometimes I feel like the world has become too fast. Everything happens so quickly that we switch to autopilot and stop thinking about why and for what purpose we are doing a task. Are we doing it in the way we imagined, or the way someone else suggested?

The Property of Complex Systems

The Property of Complex Systems

This morning, while driving to work, I encountered a much longer traffic jam than usual. “Well, with such cold weather, everyone is probably driving more cautiously,” I thought, as I slowly crawled along the Łazienkowska Route. After several minutes, I noticed from a distance that there was an accident on the opposite lane, with police and paramedics doing their work. On my side, nothing particular was happening. But still… Drivers were simply slowing down to see what was happening on the other side. No one was stopping, they were just looking. And as a result, the stretch that usually took me 5 minutes this time took 20 minutes. After passing this point, the traffic sped up significantly and flowed normally.

A Few Words About Naming – Methods (In Progress)

Note: This article is a work in progress!

Maybe the topic seems trivial and worn-out, as everyone knows that you need to create clear, unambiguous names. However, it’s still a greatly neglected area. Teams are still far from understanding that the most depends on naming. No refactoring has as much power as changing a name. It is primarily the names, if used correctly, that form what is called self-documenting code, creating a clear language in the source code of the system you are building.

Case of Scope Creep - A Simple Introduction to BDD Part 4

Introduction

In the dessert of JBehave, Behaviour-Driven Development, and the calculator (yay), we present the last part of our series.

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Have You Ever Thought About a Career as a Trainer/Consultant?

As our activities at BNS IT (bnsit.pl) continue to expand, we have openings for individuals eager to work with others to share knowledge and experience. We aim to support teams in increasing their work efficiency.

Clean Code

The Importance of Clean Code

There are ongoing philosophical discussions on whether clean code matters and if it is worth investing time to read it. I won’t engage directly in this debate. Instead, a small example should suffice:

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

You focus on the features of your IDE instead of the features your client/user needs.
You consider typing at the keyboard as thinking.
You waste countless hours manually testing your code.
You spend more time struggling with frameworks than delivering value to end users.
You code for hours without asking yourself, “What am I really doing?”
You naively believe that technologies and tools will solve your problems.
You naively believe that a good algorithm is more important than a good understanding of requirements.
You naively believe that your intuition is enough for writing good code.
You naively believe that you can manage the complexity of the system piece you’re working on.
You agree to unrealistic deadlines.
You write poor code and rationalize it with various excuses (because there is no time).
In your head, you create code snippets without really knowing what needs to be done.
You guess what needs to be done rather than clarifying.
You mindlessly follow the technology you use.
You don’t understand the tools and technologies you use.
You isolate yourself in your piece of code, breaking contact with the world.
You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Call for Code Samples

Call for Code Samples

I would gladly present the idea of the natural order of refactoring using an example code. Unfortunately, for obvious reasons, I cannot use our clients’ production code, and I do not have the time to prepare an example for this purpose. However, perhaps someone would be willing to allocate their piece of code, a project that doesn’t have too many (or any) restrictions on public publication.

Conversation with the Client

First Conversation with the Client

Today marks the beginning of a new project. As always in such cases, there is a hint of excitement in the team, as well as attempts to guess what the project will be about. We have some information, but nothing is certain yet.

How to Transform Your Programming Approach Using Refactoring

Announcing My First Book

I am pleased to announce that BNS IT has published its first book, authored by me. It’s titled “How to Completely Transform Your Programming Approach Using Refactoring.”

Weekend Workshops: Design Patterns

Invitation to Weekend Workshops on Design Patterns

We cordially invite you to the “Weekend Workshops on Design Patterns.” This is a special offer for users of the Goldenline.pl portal and readers of my blog as well as Michał’s. You won’t find this offer on the BNS IT website!

2nd Łódź JUG Meeting - Summary

2nd Łódź JUG Meeting - Summary

Yesterday, on August 9th, 2008, the second meeting of the Łódź Java User Group was held. Despite the vacation period, many enthusiasts were brave enough to devote part of their Saturday afternoon to attend a meeting dedicated to the magnificent Java programming language.

Strategies of Excellence: The Simplest Possible Environment

Download the full PDF version of the article here.

Implementation Patterns Part 1

Download the full PDF version of the article here.

Code Cleanup: Not Just About Refactoring Part 3

Introduction

Due to formatting issues on the blogspot, it is advisable to read this article as a PDF file. You can download the PDF version of the article here.

Code Cleanliness: More Than Just Refactoring Part 1

Initially, my intention was to create an article about refactoring. However, the more I pondered the subject, the clearer it became that I would not be writing solely about refactoring. It’s about something much more significant—conveying a vast amount of knowledge, essentially experience, related to code creation. Code that not only works or is well-designed but is most importantly easy to read. When we achieve this skill, we stand on the threshold of professionalism. Programming professionalism.