So I've been doing a lot of thinking and reading on the notion of functions as a first class citizens. In Python, functions are objects, just like instances of classes are objects. So when do you create a class and when do you create a function?
In my mind its somewhat a matter of style. That is, there is no mandate to use a function in place of a whole class or vise versa. That said, there are certainly times when a class is way too much work and a function will do just fine.
So a function doesn't have state, or at least it shouldn't. That means anything it knows about the world it gets as an explicit or implicit argument. Explicit arguments come in the form of parameters just like you would expect. Clearly implicit arguments should be constants or retrieved values and should never be global variables and the like.
Once you have written your function you can feel free to import it, call it, pass it around. It is pretty handy to not have to instantiate something in order to get some functionality. BUT, is this all necessary?
Again, I think we get back to a style question. I grew up on C/C++/Java with a little Perl thrown in. Discounting structured programming, in my mind everything should be an object and every object should have a class. That is clearly a habit born of Java.
I would not be critical of an application full of objects. I would not criticize a developer for never having a stand alone function. That kind of style question does not register in my lizard brain as a concern.
As I continue to play with the idea of functions as objects and functions standing alone I find myself questioning a lot of what I've learned to believe about good design. The biggest issue that occurs to me is, functions just laying about feels disorderly. I have to remind myself that the Python concept of 'module' as a means of organization has some significance. Think module == classy and it feels a tiny bit better.
Anyway, there is certainly some utility advantage to having free standing functions. For one, no tedious object instantiation. Another benefit in my mind is, you don't have to prefix a function with self. That is one of the least pleasant things in Python in my mind, all this self prefixing (same complaint about OO-Perl etc.). So if typing has somehow become the hinderence to your success, using standalone functions will save you some of that.
One other thing, in the past we've had this issue of 'where do I put utility functions'. Like convert_to_utc(datetime), a function that given a datetime in some timezone will convert it to the UTC timezone. That doesn't need a utility class, we don't need/want to do Utils().convert_to_utc(datetime) and so the function cleans that up, making it just convert_to_utc(datetime). That is one aspect of the function as a standalone/first-class object that I do appreciate. No more 'common' or 'util' classes cluttering things up.
I have some other thoughts I'll share in future posts but for now, chew on the idea that functions can be first-class citizens in your program.
23 October 2017
20 October 2017
Card Numbers
Ever notice that teams who number cards stop talking about cards and start talking about numbers?
Repeatedly I see this happen. A card is placed in a system like JIRA where it is assigned a number. Lets say AB-123. The card has a concise and meaningful title, a complete description, and all the other goodness that a card should have. Prior to being entered into the card tracking system the card was referred to as 'Spell Check Project Name Field'.
Notice, once it is placed in JIRA it is forever after referred to as AB-123.
The problem that then occurs is that the team stops talking about it as 'Spell Check Project Name Field', it becomes an abstract concept AB-123. As an abstract concept the team stops understanding and communicating it's meaning when they discuss it. As a consequence two things happen; the impact of the story isn't something that can be internalized or reasoned about and a majority of the time the team can't remember what is on AB-123, so when it comes up, nobody really understands what is being discussed.
So here is some advice, stop numbering cards and or don't allow people to talk about cards in terms of the number. Rather, enforce a behavior of discussing cards in terms of what they actually do/mean.
Repeatedly I see this happen. A card is placed in a system like JIRA where it is assigned a number. Lets say AB-123. The card has a concise and meaningful title, a complete description, and all the other goodness that a card should have. Prior to being entered into the card tracking system the card was referred to as 'Spell Check Project Name Field'.
Notice, once it is placed in JIRA it is forever after referred to as AB-123.
The problem that then occurs is that the team stops talking about it as 'Spell Check Project Name Field', it becomes an abstract concept AB-123. As an abstract concept the team stops understanding and communicating it's meaning when they discuss it. As a consequence two things happen; the impact of the story isn't something that can be internalized or reasoned about and a majority of the time the team can't remember what is on AB-123, so when it comes up, nobody really understands what is being discussed.
So here is some advice, stop numbering cards and or don't allow people to talk about cards in terms of the number. Rather, enforce a behavior of discussing cards in terms of what they actually do/mean.
18 October 2017
Preparation
You've probably heard of the 7Ps, Proper Prior Preparation Prevents Piss Poor Performance. What does that mean in the context of an agile team?
I often use the imperfect analogy of an automobile to describe an agile development team. Simply, the tires are the production system, the drive train is dev-ops, and the engine is the development team. The product owner/architect/tech-lead are the fuel delivery system to that team and stakeholders/business people are the gas-tank. When they all work together the car runs soothly down the track.
Here's the thing. If the product owner and architect aren't filtering the fuel before feeding it to the team, they aren't doing all of their job. It isn't just about pumping fuel from the tank to the developers, its also about straining out the gunk that might be in the fuel as well as distributing that work somewhat evenly across the team members. That is, making sure the fuel is clean and that every cylinder gets some of it.
I'm going to just use Product Owner as a proxy for anyone providing requirements directly to the team (Architects, Tech Leads, Engineering Leads, etc. all count as Product Owners in this scenario).
When a product owner shows up with a story, it needs to be fully digested and understood by the product owner. It needs to include answers to questions like For Whom? Why? When? and What? One essential component is of understanding that needs to be present is, what.
What means, what does this story do or accomplish and in understanding that we need some of the How, but not in a technical sense. That is, we don't need the Product Owner to provide the algorithm or a design document, but rather, How do you do the math?
An example; Calculate the percentage of ripe fruit on sale for a given date. Sounds simple enough, look in the inventory for all the fruit available for sale who's status is ripe on a given date and the total count of fruit available and do some math. But in real life that might not be a simple query. For example, we may only have available a total amount of fruit, ever. How do we do the math now? Do we deduct the entire historical record of fruit sold from total count of fruit to get fruit available? Then how do we determine ripe fruit? Same way?
This space of understanding can be solved without the business getting involved. The developers are more than smart enough to figure out a way to get an answer, but it's quite possible it won't be the right one.
So somewhere in the preparation of the card the Product Owner should have discovered this and documented it. This isn't about stealing the thunder of the brilliant developer and it isn't about providing a how; this is about communicating what is expected. That is, what ratio is the business trying to show.
I often use the imperfect analogy of an automobile to describe an agile development team. Simply, the tires are the production system, the drive train is dev-ops, and the engine is the development team. The product owner/architect/tech-lead are the fuel delivery system to that team and stakeholders/business people are the gas-tank. When they all work together the car runs soothly down the track.
Here's the thing. If the product owner and architect aren't filtering the fuel before feeding it to the team, they aren't doing all of their job. It isn't just about pumping fuel from the tank to the developers, its also about straining out the gunk that might be in the fuel as well as distributing that work somewhat evenly across the team members. That is, making sure the fuel is clean and that every cylinder gets some of it.
I'm going to just use Product Owner as a proxy for anyone providing requirements directly to the team (Architects, Tech Leads, Engineering Leads, etc. all count as Product Owners in this scenario).
When a product owner shows up with a story, it needs to be fully digested and understood by the product owner. It needs to include answers to questions like For Whom? Why? When? and What? One essential component is of understanding that needs to be present is, what.
What means, what does this story do or accomplish and in understanding that we need some of the How, but not in a technical sense. That is, we don't need the Product Owner to provide the algorithm or a design document, but rather, How do you do the math?
An example; Calculate the percentage of ripe fruit on sale for a given date. Sounds simple enough, look in the inventory for all the fruit available for sale who's status is ripe on a given date and the total count of fruit available and do some math. But in real life that might not be a simple query. For example, we may only have available a total amount of fruit, ever. How do we do the math now? Do we deduct the entire historical record of fruit sold from total count of fruit to get fruit available? Then how do we determine ripe fruit? Same way?
This space of understanding can be solved without the business getting involved. The developers are more than smart enough to figure out a way to get an answer, but it's quite possible it won't be the right one.
So somewhere in the preparation of the card the Product Owner should have discovered this and documented it. This isn't about stealing the thunder of the brilliant developer and it isn't about providing a how; this is about communicating what is expected. That is, what ratio is the business trying to show.
17 October 2017
Delays
Hello again. I was sick over the weekend and failed to get a post out on Monday. That has taken me on a tangent to thinking about delays.
So one of my projects is now effectively delayed because I was unavailable. I'm sure we will recover, I just need to make up for that keyboard time and we'll be back on track. But this impacts our delivery date. I now need to work some more hours durning the week to make up the difference.
Similarly, on another project we're running into a problem of stakeholder availability. A few of the stories we are working on have come to a halt because we don't have a complete understanding of the business needs or the technical details. Each of those stories has been delayed. An interesting side effect of this is that we are stretching our WIP limit because we're picking up other work to fill the gap.
In the first case we have a pretty simple case of needing to just rearrange the only work schedule because of a lack of resources to do the work. It's a simple solve. Given more staff we could have just swapped in another developer to do that work. Since we don't have more staff, we just shift the schedule.
In the second case we have plenty of worker resources. The issue here is a lack of executable work, leaving worker resources idle. Whats interesting to me is that, as a result of having too many workers and blocked cards do to incomplete specs, we have pulled more work into the system to prevent idleness. As a consequence the load on the team, in terms of things to keep track of/manage is increased, but the productivity is unchanged as best and possible decreased if the cards remain blocked.
So this second case is whats most interesting to me. In an attempt to keep all resources utilized we add work to the In Progress list and mark other work blocked. In particular, because we're waiting on an external resource (Stakeholder) to answer a question. Back in the day we would have asked our product owner, who was sitting in the room, to help us get the answer and we would have actively pursued that answer until it was either found or determined to be unanswerable. In the later case we would discard all the work and move on to another card.
We seem to have adopted a 'wait for the answer' posture, one that is even passive. That to me shouldn't be acceptable. Rather, we should work to engage the stakeholder in a manner that encourages them to give up the goods on demand OR have given it up in advance.
In advance is a problem though. In my Shangri-La the product owner is in the room and ready to answer questions at all times, no advanced planning necessary; but thats not reality. In reality, where we actually live, the product owner/tech-lead team have looked at, though through, and triaged all the cards before the development team sees them. They have at least a minimum amount of information ready and available to answer the teams questions. [I'm not saying that info is necessarily on the cards, just that its readily available]
While this doesn't conform exactly to the 'A card is a promise for a conversation' ideal, if a card could be a proxy for pre-digested (by the PO/TL pair) answers to expected/common questions it will impart efficiency into the process of delivering the story.
I recognize that this is similar to the Definition of Ready that some teams use, but I see a difference in how it is applied. The DoR is typically applied as a gate keeper on the 'Ready' column for the team; if the check boxes aren't checked then the card can't be added. Rarely, if ever, do I see the Product Owner or Tech Lead using the DoR as a check list for preparing work; and when I have it's been an awful disaster.
Somewhere between the DoR and a card with two or three words on it is an place where the Product Owner and the Tech Lead understand enough of the details of a card that they can answer reasonable questions about it without having to wait for an external stakeholder and/or a series of spikes to be completed.
I'm way over my length goal here, so I'll save my thoughts on the realistic solution to this problem for another post.
So one of my projects is now effectively delayed because I was unavailable. I'm sure we will recover, I just need to make up for that keyboard time and we'll be back on track. But this impacts our delivery date. I now need to work some more hours durning the week to make up the difference.
Similarly, on another project we're running into a problem of stakeholder availability. A few of the stories we are working on have come to a halt because we don't have a complete understanding of the business needs or the technical details. Each of those stories has been delayed. An interesting side effect of this is that we are stretching our WIP limit because we're picking up other work to fill the gap.
In the first case we have a pretty simple case of needing to just rearrange the only work schedule because of a lack of resources to do the work. It's a simple solve. Given more staff we could have just swapped in another developer to do that work. Since we don't have more staff, we just shift the schedule.
In the second case we have plenty of worker resources. The issue here is a lack of executable work, leaving worker resources idle. Whats interesting to me is that, as a result of having too many workers and blocked cards do to incomplete specs, we have pulled more work into the system to prevent idleness. As a consequence the load on the team, in terms of things to keep track of/manage is increased, but the productivity is unchanged as best and possible decreased if the cards remain blocked.
So this second case is whats most interesting to me. In an attempt to keep all resources utilized we add work to the In Progress list and mark other work blocked. In particular, because we're waiting on an external resource (Stakeholder) to answer a question. Back in the day we would have asked our product owner, who was sitting in the room, to help us get the answer and we would have actively pursued that answer until it was either found or determined to be unanswerable. In the later case we would discard all the work and move on to another card.
We seem to have adopted a 'wait for the answer' posture, one that is even passive. That to me shouldn't be acceptable. Rather, we should work to engage the stakeholder in a manner that encourages them to give up the goods on demand OR have given it up in advance.
In advance is a problem though. In my Shangri-La the product owner is in the room and ready to answer questions at all times, no advanced planning necessary; but thats not reality. In reality, where we actually live, the product owner/tech-lead team have looked at, though through, and triaged all the cards before the development team sees them. They have at least a minimum amount of information ready and available to answer the teams questions. [I'm not saying that info is necessarily on the cards, just that its readily available]
While this doesn't conform exactly to the 'A card is a promise for a conversation' ideal, if a card could be a proxy for pre-digested (by the PO/TL pair) answers to expected/common questions it will impart efficiency into the process of delivering the story.
I recognize that this is similar to the Definition of Ready that some teams use, but I see a difference in how it is applied. The DoR is typically applied as a gate keeper on the 'Ready' column for the team; if the check boxes aren't checked then the card can't be added. Rarely, if ever, do I see the Product Owner or Tech Lead using the DoR as a check list for preparing work; and when I have it's been an awful disaster.
Somewhere between the DoR and a card with two or three words on it is an place where the Product Owner and the Tech Lead understand enough of the details of a card that they can answer reasonable questions about it without having to wait for an external stakeholder and/or a series of spikes to be completed.
I'm way over my length goal here, so I'll save my thoughts on the realistic solution to this problem for another post.
13 October 2017
Criticism -- You're language is no good
So I was reading an article the other day, suggested by someone I work with, and it had some very disparaging things to say about Java.
It got me thinking, why does Java have a reputation for being overly verbose and full of interfaces and such. C# seems to have a similar reputation.
But heres the thing, it's not the language that's doing all that. Its the frameworks, the books, and the people. The language doesn't care.
I have to agree that Java has some overhead involved just by its very nature, but it is mostly easy to use otherwise. Sure, it's statically typed and has some limitations (though gradually many of those are going away) but the language doesn't force you into creating a bunch of interfaces and having super complex structures to get things done.
So why do we keep beating up on the language? Why, instead, are we not critical of the people who write the code like that? And the designers who create frameworks that force us to write code like that.
I'll admit, I've written some insanely complicated Java in my time, but I learned that I wasn't getting any advantage from doing so and I quit doing it. Now, for the most part, my Java is pretty clean and simple. At least as much as I can make it be within the limitations of the language.
I have read a fair amount of open source code. Not as much as others, but certainly my fair share. I think some of the code out there is way over complicated. Sometimes its just down right ridiculous. And it doesn't matter if it's Java or Python or Ruby or anything else. So why does Java (or C#) get the bad rap?
I'm heading somewhere with this line of thinking, but I'm not sure where yet. I've been trying to get this much out of my head for 3 days. It's hard to do without sounding like a lunatic.
More later I hope.
It got me thinking, why does Java have a reputation for being overly verbose and full of interfaces and such. C# seems to have a similar reputation.
But heres the thing, it's not the language that's doing all that. Its the frameworks, the books, and the people. The language doesn't care.
I have to agree that Java has some overhead involved just by its very nature, but it is mostly easy to use otherwise. Sure, it's statically typed and has some limitations (though gradually many of those are going away) but the language doesn't force you into creating a bunch of interfaces and having super complex structures to get things done.
So why do we keep beating up on the language? Why, instead, are we not critical of the people who write the code like that? And the designers who create frameworks that force us to write code like that.
I'll admit, I've written some insanely complicated Java in my time, but I learned that I wasn't getting any advantage from doing so and I quit doing it. Now, for the most part, my Java is pretty clean and simple. At least as much as I can make it be within the limitations of the language.
I have read a fair amount of open source code. Not as much as others, but certainly my fair share. I think some of the code out there is way over complicated. Sometimes its just down right ridiculous. And it doesn't matter if it's Java or Python or Ruby or anything else. So why does Java (or C#) get the bad rap?
I'm heading somewhere with this line of thinking, but I'm not sure where yet. I've been trying to get this much out of my head for 3 days. It's hard to do without sounding like a lunatic.
More later I hope.
11 October 2017
Dogma
So getting back into the blogging rhythm is proving challenge. I'm going to try to do the 3x a week thing again, but I might be a bit uneven on the delivery while I get back into it. Please be patient, I'm just rearranging my self a bit too much right now, but I'll get there.
--------------
Apropos nothing and everything at the same time, Dogma is BAD.
Blind adherence to a method or practice leads to stagnation and complacence.
Right at the moment I'm working on learning and understanding some subtleties of using functions as first class objects and how that impacts. What I'm looking for is the balance point between too much and too little of this approach.
I'm doing this first because I want to learn something; something I hope will improve my skills as a developer. Secondly, in conversation about exactly this it was difficult to articulate how much of this should and should not be done.
After that discussion a few links to various sources were provided and I started digging into this idea. Coming from a C++/Java background originally I'd bought into the idea that everything is an object, if it isn't an object it shouldn't exist (with all the necessary caveats necessary to digest C++ and Java).
So, if I accept that that isn't necessarily true (reject dogma) then I need to embrace this new approach. First I need to really understand it and how it works, but then I need to really get into the subtle parts so I can speak coherently about it.
This is just one example of the whole dogma thing. You've heard me speak about 'creating cards' and 'you have to because the process says so' etc. elsewhere. The same stuff applies to things like OOD and idiomatic Python or 'Standard Java'.
All of this has inspired a bunch of other thoughts I hope to share soon.
--------------
Apropos nothing and everything at the same time, Dogma is BAD.
Blind adherence to a method or practice leads to stagnation and complacence.
Right at the moment I'm working on learning and understanding some subtleties of using functions as first class objects and how that impacts. What I'm looking for is the balance point between too much and too little of this approach.
I'm doing this first because I want to learn something; something I hope will improve my skills as a developer. Secondly, in conversation about exactly this it was difficult to articulate how much of this should and should not be done.
After that discussion a few links to various sources were provided and I started digging into this idea. Coming from a C++/Java background originally I'd bought into the idea that everything is an object, if it isn't an object it shouldn't exist (with all the necessary caveats necessary to digest C++ and Java).
So, if I accept that that isn't necessarily true (reject dogma) then I need to embrace this new approach. First I need to really understand it and how it works, but then I need to really get into the subtle parts so I can speak coherently about it.
This is just one example of the whole dogma thing. You've heard me speak about 'creating cards' and 'you have to because the process says so' etc. elsewhere. The same stuff applies to things like OOD and idiomatic Python or 'Standard Java'.
All of this has inspired a bunch of other thoughts I hope to share soon.
09 October 2017
Trust
Welcome back! I missed you.
I had to take a short break from blogging. I got a little overwhelmed with too many things and blogging fell to the wayside.
So I've been thinking about trust for a couple days now and its role in the team room and in collaborations in general. I'm not going to role out a bunch of quips about trust here, I want to talk about it's value though.
Without trust in a team there can be some serious consequences. A simple consequence is that when team members don't trust each other they can burn a lot of energy second guessing each others work. Related to that, individuals can burn a lot of energy speculating about what their team mates are doing.
Thats a lot of wasted energy.
So how do you develop trust in a team? I think there are a lot of ways, and I won't claim to know them all. My usual reply is 'drinking!'. But more seriously, it is important to develop a human connection between team members. That can be as easy as asking how someone is doing, what they did over the weekend, or if they need some help. Just being a human being is necessary, and will eventually lead to trust.
There is another critical component to developing trust. You have to listen to each other. When I say listen, I don't mean wait for the other person to stop talking, that's being polite, I mean actually hear and process what they have said.
We don't have to agree all the time, and we don't have to have groupthink, but if we aren't even allowing alternate opinions to be voiced, in addition to showing a lack of respect, we are fostering a lack of trust. Consider the view point of the speaker; when you ignore or shutdown their words you are telling them you don't care about what they have to say -- you are telling them you don't trust them. Now ask, why should they trust you?
I had to take a short break from blogging. I got a little overwhelmed with too many things and blogging fell to the wayside.
So I've been thinking about trust for a couple days now and its role in the team room and in collaborations in general. I'm not going to role out a bunch of quips about trust here, I want to talk about it's value though.
Without trust in a team there can be some serious consequences. A simple consequence is that when team members don't trust each other they can burn a lot of energy second guessing each others work. Related to that, individuals can burn a lot of energy speculating about what their team mates are doing.
Thats a lot of wasted energy.
So how do you develop trust in a team? I think there are a lot of ways, and I won't claim to know them all. My usual reply is 'drinking!'. But more seriously, it is important to develop a human connection between team members. That can be as easy as asking how someone is doing, what they did over the weekend, or if they need some help. Just being a human being is necessary, and will eventually lead to trust.
There is another critical component to developing trust. You have to listen to each other. When I say listen, I don't mean wait for the other person to stop talking, that's being polite, I mean actually hear and process what they have said.
We don't have to agree all the time, and we don't have to have groupthink, but if we aren't even allowing alternate opinions to be voiced, in addition to showing a lack of respect, we are fostering a lack of trust. Consider the view point of the speaker; when you ignore or shutdown their words you are telling them you don't care about what they have to say -- you are telling them you don't trust them. Now ask, why should they trust you?
Subscribe to:
Posts (Atom)