Also available in Czech, kindly translated by Aleš Roubíček
Writing Legacy Code is a distributed activity.
Oh, no! Bad code again
You have been assigned a new task.
Your mission: to add a simple feature to a Corporate project. You know almost nothing about it, but the feature request sounds feasible. You can easily accomplish the task.
This is what you think. Until you open the code base.
I agree with Michael Kennedy when he says that Software Development could be modeled as a Knowledge Discovery Process, “the process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer“.
I agree so much that I decided to adapt my future Daily Scrums to this.
Well, if only I had seen then what I saw today, I would have used in my talk, since I think it would have been the perfect example.
See what I found in a recent production code.
Right now, it hangs on the wall of our open space, for all the developers to see.
Rule #1: write commit comments before coding
Rule #2: write what the software should be supposed to do, not what you did
I wasn’t able to be concise enough. Since Susana’s question made me think of three other questions which I do not know the answers, I’m sharing them with you all.
Find here the follow-up of this post.
I find it vaguely irritating when the abused image in which software is described as an intangible product is used.
Software is, of course, intangible as of dictionary definition (“Incapable of being perceived by the senses, Incorporeal“) since it’s made of bits and bits obviously cannot be touched.
But this is not the abuse I’m talking about. The annoying cliché used in tons of posts and articles speciously refers to another meaning, and it’s very often used by-end.
This the second part of How I Was Able To Be Successful Even When Forced To Use Waterfall
Rule #1: take your time
Luckily, your estimation meeting will be much more fortunate than mine (see Part I).
In my previous Scrummerfall experience, since I was forced to produce a big-planning-up-front phase, I was used to always plan 2 or 3 days for it. I was asking for an estimation when my ignorance of the problem was at the maximum level, hence I needed a lot of analysis.
Concerto collects some ideas for a better and more effective board to be used in Agile projects.
For an unfortunate coincidence, I chose the same name of the famous Parasoft’s development management software, which I didn’t know before.
Concerto board has nothing to do with Parasoft.
This post is going to be pretty long.
Feel free to scroll down, or roll the paragraphs, if you think.
I’m pretty sure you will entirely read it later, since it is really interesting.
In case of panic, click here to jump to conclusions.
Managing The Development Of Large Software Systems
I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine: years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis.
Waterfall can work
No it cannot.
I mean: actually, it does, but adopting new and modern methodologies, you can dramatically improve your team productivity.
Yet, I believe most teams are using a mix of Agile and Waterfall. The reason is Waterfall is the sole methodology able to give the only information your manager needs to know: how much the project will cost and what’s the delivery date. About this, read the excellent post by Christopher Goldsbury Why Agile Adoption Fails in Some Organizations
I once worked as a team leader in a startup. I was in love with XP, studying Scrum and looking forward to be able to put into practice what I was reading.
Unfortunately, my boss explicitly told me to use Waterfall. I never blamed him: before him, the company had no process at all, and was governed by anarchy; no documentation, no requirements, no clear roles. Actually, introducing a Waterfall process, he made a great revolution, and let the company succeed.
var it = new MP3(); sam.play(it); sam.play(it); @chrisoldwood $Apocalypse = now(); @johnnypixel 10 IF ALL WORK NO PLAY 20 THEN JACK = DULL BOY 30 GOTO 10 @andrewfconex c.beginPath(); c.fillStyle="#0f0"; c.lineTo(63360*72,0); c.stroke(); @adomas_s echo $bible['Eze']; kill(); @arialdomartini
Please, help me to understand what I’m missing.
When a unit test for a method implementing some feature is green, it does not mean the feature is working. The corresponding end-to-end or integration tests reveal if it’s working or if it’s broken. To Product Owner’s point of view, end-to-end tests are all that matters. Unit tests are useless.
Unit tests are meant to lie. They rely on the often wrong assumption that the rest of the world is correctly working, but only because they are explicitly mocking it: using a fake world is a deliberate lie.
To me, that’s exactly why they are so useful.