You’re starting off with a new laptop. The OS is installed, but using it feels awkward. A few days later you feel the flow again. Your Agile process also needs to fit your workflow.
It's no wonder that organizations strive to groom their decision-making processes, and today I want to highlight a quite common disconnect, observed not only in software development companies, but in all kinds of organizations, as well as in municipal and government bodies.
Test suites are one of the tools we have to improve the quality of software while we're building it; they are particularly fitting for checking functional requirements and some other properties such as performance and some forms of maintainability. However, there are other critical properties that may be important in your project and that your test suite cannot help you in fixing. However, we still can put in place processes that give us feedback on the matter, such as security audits, code review and pair programming for maintainability, and higher-level models than code for concurrency issues. Tests are a tool, not an end.
This week we're talking to Lukas Eder, creator of jOOQ, a SQL library for Java, and Founder/CEO of Data Geekery.
The concept of a Minimal Viable Product has a lot of traction, and for good reason. It talks about building the smallest thing you can that will let you learn if the product is going in the right direction.
A friend of mine told me about an organization in trouble: They were too firmly attached to their processes to improve when needed. The strict process that was followed? Agile (Scrum to be specific). Using an agile process the wrong way can give exactly the same problems that the agile movement tried to extinguish.
Here’s how this implication manifests itself. The example that I have presented here comes from years of my work with leads and customers. You probably know that they tend to want more and more new features from the software product they’re using, or just looking at.
A quick recap of the problem: implement binary search, a classic algorithm, over a sorted array (or your preferred random-access linear data structure, depending on your programming language.) You should compare different programming styles and paradigms if you can, with the goal of stimulating your creativity to find 5 different ways to implement the algorithm.
Any meeting includes three components: the problem, the goal, and the people. The so-called technical meeting is where the components fit best. Such meetings can happen on the fly as two to three experts discuss a clearly outlined technical problem, looking for a clearly outlined goal.
After doing more managing than normal and getting back to coding, I realize just how much I like to code and, why ...
Have any of the lines of code I have written changed a person’s life for the better? How can I tell? The separation feels unnecessary, we are all people, can we really not meet? I’d be inspired. I’d be able to build something of value.
ls -l --time-style="+%Y-%m-%d %H:%M" -tr
For the experienced software developers out there, I have a question: what are the main things you believe, based on your experience, most influence the success of a software project?
I’ve met people who have developers all over the US and testers in the Far East. Every single time I hear the same story: The delays in the project are overwhelming. Why does senior management do this? Because they do not realize that software is about design and learning. When senior managers think software is like manufacturing, they miss the essence of software: collaboration.