It should have occurred to me much earlier to put it like this: what an FA really is ... it's the Product Owner in SCRUM ... bridges the gap between the technical and business worlds, OWNs stuff, takes DECISIONS!
And I am telling you: It has never ever been easier than today to take decisions in software!
And here is why:
1. We are encouraged to take risks. Risks may bring in failure. Goto line 2.
2. We are taught that failure is part of the game.
3. We are taught to embrace change, change brings in risks. Go to line 1.
4. Agile practices tell us that upfront planning is not the thing to do. Without complete upfront planning, risks are higher. Goto line 1.
5. There is so much complexity, so many unknowns, so much competition that getting it wrong will not be a surprise.
6. There is this notion of a throwaway prototype. In case your feature fails, declare it was a throwaway protoype.
7. There are so many other smart boys in the industry that simply could not figure it out!
8. Management continuously pushes us to innovate. Innovation leads to uncertainty, uncertainty leads to risk, goto line 1.
9. If you are working in an enterprise, high chances that you are part of a feature team. As opposed to component teams, features teams do not specialize in certain product areas but instead are mobile and take tasks in multiple areas of the product. This implies they do not own stuff, the ownership is collective. This implies collective risk taking. Thus collective blaming. But since management can not afford to send an entire team home ... you see my point.
So step up into this role. You'll have visibility, you'll be admired, you'll get your pay raise. Just be armed with the knowledge above for the 1:1 with your boss when you mess it up.
Take decisions. Or somebody else will. You're definitely smarter than somebody else!
Thursday, March 16, 2017
Thursday, March 31, 2016
the tools that saved the OS ... [2]
Fresh from MS Build conference, the Ubuntu on Windows project is along the lines of this older post of mine.
After this project goes live, it will be interesting to watch if the usage of Cygwin in Windows 10 will be lower than that in Windows 7.
After this project goes live, it will be interesting to watch if the usage of Cygwin in Windows 10 will be lower than that in Windows 7.
Wednesday, January 27, 2016
the bold and the bullshit
The high demand for software professionals transformed them into these picky creatures that indulge with free lunches, fusball tables, designer office spaces, paid membership at the gym, sponsored medical care, company matched volunteering programs, and massages at the office.
Hiring software professionals has become the HR's nightmare. Annual reviews don't scare anyone, as a low performance review can be followed up with a new job in another company that is craving to grow past the 500 figure to appear on the radar of Western companies looking for outsourcing partners ... hugh, that was quite a long sentence.
This is the perfect context for being bold. It is not about saving the long-haired blond Princess from the jaws of the hungry Lion, nor the Kid who is drowning in the muddy waters of Amazon. These deeds had been done by other heroes.
I am talking this bold:
- adopt a no bullshit policy
- give honest feedback
- contribute to discussions, even if you start with "I think ..."
- have the courage to say "I don't know shit about this"
- have the courage to say "This meeting is a waste of my time"
- keep your desk messy ... actually I see a lot of these heroes
We are talking opportunity here: act like this while you still can laugh at the prospect of being fired.
And this is all for your own good. Philosophy says that sincerity boosts happiness, and science that happiness fuels success. (Warning: some say that success is the inverse of happiness, so you be the judge; but if you go for happiness first, it might redefine success.)
Oh oh, let me not get all too involved in this philosophy - science - beliefs ... philosophy, and step back a little ... you are an engineer right? so Success must be what you are looking for ... gotcha ya you little un-bold prick!
Hiring software professionals has become the HR's nightmare. Annual reviews don't scare anyone, as a low performance review can be followed up with a new job in another company that is craving to grow past the 500 figure to appear on the radar of Western companies looking for outsourcing partners ... hugh, that was quite a long sentence.
This is the perfect context for being bold. It is not about saving the long-haired blond Princess from the jaws of the hungry Lion, nor the Kid who is drowning in the muddy waters of Amazon. These deeds had been done by other heroes.
I am talking this bold:
- adopt a no bullshit policy
- give honest feedback
- contribute to discussions, even if you start with "I think ..."
- have the courage to say "I don't know shit about this"
- have the courage to say "This meeting is a waste of my time"
- keep your desk messy ... actually I see a lot of these heroes
We are talking opportunity here: act like this while you still can laugh at the prospect of being fired.
And this is all for your own good. Philosophy says that sincerity boosts happiness, and science that happiness fuels success. (Warning: some say that success is the inverse of happiness, so you be the judge; but if you go for happiness first, it might redefine success.)
Oh oh, let me not get all too involved in this philosophy - science - beliefs ... philosophy, and step back a little ... you are an engineer right? so Success must be what you are looking for ... gotcha ya you little un-bold prick!
Tuesday, February 10, 2015
structuring Python's main()
You would not imagine that such a seemingly trivial topic deserves a blog post of its own. Until you see this:
def main(argv=None):
if argv is None:
argv = sys.argv
opt, args = parser.parse_args(argv[1:])
(1) opts_args defaults to [] instead of None, because calling parser.parse_args(None) will actually parse sys.argv[1:] (see optparse.py), and you don't want this if calling main() from another script.
(2) if you want to use the script name in the help message, __file__ should do, you don't need sys.argv[0]
(3) all sys code in one place
def main(argv=None):
if argv is None:
argv = sys.argv
opt, args = parser.parse_args(argv[1:])
...and this
repeatedly in the code, and you start thinking this is a pattern somebody defined elsewhere. And indeed it is, find Guido's original article here.
From the issues that the original post addresses, let me only focus on the ones printed above, so mainly leaving out the details of argument parsing and displaying the usage message.
We are after a function that's easy to invoke in other contexts, e.g. from the interactive Python prompt.
Let's add print statements for opt and args and run the code above from the command line:
if __name__ == "__main__":
sys.exit(main())
sys.exit(main())
repeatedly in the code, and you start thinking this is a pattern somebody defined elsewhere. And indeed it is, find Guido's original article here.
From the issues that the original post addresses, let me only focus on the ones printed above, so mainly leaving out the details of argument parsing and displaying the usage message.
We are after a function that's easy to invoke in other contexts, e.g. from the interactive Python prompt.
Let's add print statements for opt and args and run the code above from the command line:
c:\Temp>c:\Python27\python test.py arg1 arg2
{}
['arg1', 'arg2']
And let's call it from the interactive shell, looking after the same behavior:
c:\Temp>c:\Python27\python
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> test.main(['arg1', 'arg2'])
{}
['arg2']
>>> test.main(['arg_that_nobody_cares_of', 'arg1', 'arg2'])
{}
['arg1', 'arg2']
You'll also feel the smell once you try to document it:
def main(argv=None):
"""
Parses argv and prints the results as parsed by optparse.OptionParser.parse_args(), after dropping argv[0]. So if calling it from another script, make sure the args you care about start at index 1.
Keyword arguments:
argv: array of options and arguments. If None, it defaults to sys.argv.
"""
I would argue that main() should exhibit the same behavior when called the same way from different contexts and expose a consistent interface. Here is the proposal:
def main(opts_args=[]): # (1)
opt, args = parser.parse_args(opts_args) # (2)
if __name__ == "__main__":
sys.exit(main(sys.argv[1:])) # (3)
(2) if you want to use the script name in the help message, __file__ should do, you don't need sys.argv[0]
(3) all sys code in one place
Thursday, October 23, 2014
I'm already used, you know?!
Every once in a while I come across a type that it is documented as being used by another type:
/**
* Used by {@link SupremeCook} to bake supreme cakes.
*/
public class NewFlavor { ... }
As the author of a blog takes pride into having his posts read by many individuals, it would be the pride of the author of a type to have it reused as much as possible within the codebase.
Practicing over-documentation, the author of the type above softly coupled it with another type, defeating the above stated goal by making potential new users think the new type was not designed for reusability ...
3 years have passed by ...
Miles and miles away from our programmer, in a remote conference room in a remote part of the world, upon being advised by his lawyers, the young entrepreneur decided to withdraw the flavor packages still on the supermarket shelves to make the following correction to the usage instructions:
/**
* Used by {@link SupremeCook} to bake supreme cakes.
*/
public class NewFlavor { ... }
As the author of a blog takes pride into having his posts read by many individuals, it would be the pride of the author of a type to have it reused as much as possible within the codebase.
Practicing over-documentation, the author of the type above softly coupled it with another type, defeating the above stated goal by making potential new users think the new type was not designed for reusability ...
3 years have passed by ...
Miles and miles away from our programmer, in a remote conference room in a remote part of the world, upon being advised by his lawyers, the young entrepreneur decided to withdraw the flavor packages still on the supermarket shelves to make the following correction to the usage instructions:
Friday, July 18, 2014
not by the book
How would you cope with entering an idea brainstorming meeting and the very first words the organizer says are along these lines "Welcome, here is an idea I had this morning, please help me refine it"?
Today I've wanted to make people approach something ordinary (be in a meeting) into an out of the ordinary way (not be aware of any meeting process or outcomes).
So I entered the room. And I said something along these lines "Welcome, here is an idea I had this morning, please help me refine it".
So they were all ears, then timidly contributed to the idea, but there was something missing in the air. Then one person did the unimaginable: my meeting co-organizer broke a deal I had made with him hours before the meeting: that there would be no slides.
He professionally waited until the conversation paused a little. Then there they were:
Today I've wanted to make people approach something ordinary (be in a meeting) into an out of the ordinary way (not be aware of any meeting process or outcomes).
So I entered the room. And I said something along these lines "Welcome, here is an idea I had this morning, please help me refine it".
So they were all ears, then timidly contributed to the idea, but there was something missing in the air. Then one person did the unimaginable: my meeting co-organizer broke a deal I had made with him hours before the meeting: that there would be no slides.
He professionally waited until the conversation paused a little. Then there they were:
THE SLIDES
The slides I've tried to part with. I could, but he could not. Or maybe they could not.
I imagine he could not stand the situation anymore. Or he noticed that others could not stand the situation anymore, and he wanted to avoid a failed meeting. Because they needed
THE RULES
They attentively watched the 4 slides unrolling before their eyes, and then all was fine. The sky was clear again. Ideas started flowing, 6 in one hour. Astonishing. 3 people left the room to attend other duties or answer the phone and came back. One KPI checked. It was a "really good, 4/5 meeting" said one of the participants afterwards.
But in the thin air _they_ were still there. Waiting to bite us again.
What do we do with these ideas?
Who is taking this further?
When can we expect results?
This was a closed-door meeting, how will we let the others know about such next meetings?
They needed
MORE RULES
But there is a line. Cause we only need just enough rules to allow us to have no rules.
Cause we don't need a formal email to let the others know what we did today. They will hear it from the participants if they left the meeting excited.
Plus I and my co-organizer will repeat the same meeting with another group, possibly half of today's participants and half first-comers. Why half of the ones from today's meeting? Simple, because they already know
THE RULES
Friday, March 7, 2014
are you the next FA (3)?
Every now and then I can not help but admire what StackOverflow has become. Tricky errors scare no one anymore. Badges make you feel stronger than ever. People take pride in contributing there. Resumes display the reputation.
So if the word Functional in the job title Functional Architect is not music to your ears, and you long for the more handsome System Architect title, take note that it is the functional aspects that made StackOverflow what it is today, what made the difference between the other thousand forums with the same intent of helping users in trouble and StackOverflow.
So if the word Functional in the job title Functional Architect is not music to your ears, and you long for the more handsome System Architect title, take note that it is the functional aspects that made StackOverflow what it is today, what made the difference between the other thousand forums with the same intent of helping users in trouble and StackOverflow.
Monday, February 17, 2014
the tools that saved the OS ...
... with no decent console.
... until some Windows lover coded Total Commander and another Windows lover coded Cygwin (although I have my doubts about the real object of love for the latter). Navigate folders easily in TC, script your day out in a *nix shell.
Here is a very simple and updated (older tricks here) guide of how-to open Cygwin in Total Commander's current directory (tested for TC 8.01 x64 and Cygwin 2.819 x64):
1. create a start menu command in TC and use the original invocation line the Cygwin installer uses:
2. add this to your ~/.bash_profile
... until some Windows lover coded Total Commander and another Windows lover coded Cygwin (although I have my doubts about the real object of love for the latter). Navigate folders easily in TC, script your day out in a *nix shell.
Here is a very simple and updated (older tricks here) guide of how-to open Cygwin in Total Commander's current directory (tested for TC 8.01 x64 and Cygwin 2.819 x64):
1. create a start menu command in TC and use the original invocation line the Cygwin installer uses:
2. add this to your ~/.bash_profile
cd "$OLDPWD"Then you'll be able to use this power key (Alt + s + c, notice the &c in the menu title) to open Cygwin in your current folder.
Wednesday, January 29, 2014
get some drawing lessons
It was not my intention at all, but I somehow "stole" the best idea of the morning meeting today. To my defense, it was only the order of the speakers that determined that the good idea was first to be uttered by another participant.
QA practices around automated tests had to be changed, so we had to convince the QA manager.
At one moment, THE IDEA was uttered. By someone else from my team. The idea that would start to change the game. Beautifully decorated with solid arguments. Verbal arguments. Things became uncertain, the manager started frowning. So we threw in more words. He needed to think, he would come back to us.
Then I did the drawing.
The drawing that we looked at during the rest of the meeting. That we pointed at when bringing in more and more arguments. That made it my idea:
In the software world, the question is simple: can you or can you not draw?
QA practices around automated tests had to be changed, so we had to convince the QA manager.
At one moment, THE IDEA was uttered. By someone else from my team. The idea that would start to change the game. Beautifully decorated with solid arguments. Verbal arguments. Things became uncertain, the manager started frowning. So we threw in more words. He needed to think, he would come back to us.
Then I did the drawing.
The drawing that we looked at during the rest of the meeting. That we pointed at when bringing in more and more arguments. That made it my idea:
In the software world, the question is simple: can you or can you not draw?
Wednesday, November 6, 2013
in love with waterfall
Even if your company has forced you into SCRUM, if you are an influential team member or the mighty scrum master itself, you can find ways to keep your love close. Directly speaking, you can change SCRUM to still irradiate the warmth of the lost loved one. And it is even legal.
So I am suggesting you a new scrum but. Written by the book, it could say:
So I am suggesting you a new scrum but. Written by the book, it could say:
(We use SCRUM, but) (because we are in love with waterfall,) (developers speak first and only then testers in our daily stand-ups)
but it can be masked as:
(We use SCRUM, but) (because testers can not test unless developers develop,) (developers speak first and only then testers in our daily stand-ups)
I've seen this applied, so it's proven to work!
Thursday, July 4, 2013
marketing
These two guys definitely think that marketing should be in the toolbox of every developer.
So you follow the above links recursively until you know everything about the two and marketing in general, evaluate how credible the two are, and then start to think if what they say makes sense.
And it does seem to make sense: market yourself, market your stuff! And then you think: Hold you horses, I work in this cube of this big corporation, there are others in other roles that will do the marketing, I can just code.
It happens that recently in one All-hands we've had, I've heard one of our PMs say something along these lines: We need to sell our new features to the Sales guys first, and then they can sell them further. And some time before this, I had heard our Director saying something along these other lines: We need to sell our product better to the Software org, so that it will count in the next product stack.
It all adds up, don't you think? But will a time come when you'll have to sell your stuff to the product director? Or to your manager?
... I don't think so, you're just a poor soul in a cubicle, right?!
So you follow the above links recursively until you know everything about the two and marketing in general, evaluate how credible the two are, and then start to think if what they say makes sense.
And it does seem to make sense: market yourself, market your stuff! And then you think: Hold you horses, I work in this cube of this big corporation, there are others in other roles that will do the marketing, I can just code.
It happens that recently in one All-hands we've had, I've heard one of our PMs say something along these lines: We need to sell our new features to the Sales guys first, and then they can sell them further. And some time before this, I had heard our Director saying something along these other lines: We need to sell our product better to the Software org, so that it will count in the next product stack.
It all adds up, don't you think? But will a time come when you'll have to sell your stuff to the product director? Or to your manager?
... I don't think so, you're just a poor soul in a cubicle, right?!
Wednesday, May 15, 2013
let go (II)
To the one thinking about a software architect career, the bad news is that the LET GO advice applies to you as well! The good news is that it does not apply as drastically as for managers, so you might get your share of coding.
But what are the shares that you're "winning"? Creating a vision of the product, technical communication with the stakeholders, sharing the project risks with the project manager (agilists do not have a project manager role in their team and they are perfectly fine with that, no extra comments allowed :/).
I heard this guy saying yesterday that one characteristic you should look for in your next architect is that of being able and willing to step back. He was referring probably to stepping back in order to get the big picture. One other thing that he said was that he had seen cases when the software architecture was not properly looked after because the architect was too busy writing code and/or keeping up with new technologies.
This is what I'm saying! We should look for people who are also able and willing to let go!
But what are the shares that you're "winning"? Creating a vision of the product, technical communication with the stakeholders, sharing the project risks with the project manager (agilists do not have a project manager role in their team and they are perfectly fine with that, no extra comments allowed :/).
I heard this guy saying yesterday that one characteristic you should look for in your next architect is that of being able and willing to step back. He was referring probably to stepping back in order to get the big picture. One other thing that he said was that he had seen cases when the software architecture was not properly looked after because the architect was too busy writing code and/or keeping up with new technologies.
This is what I'm saying! We should look for people who are also able and willing to let go!
Tuesday, February 12, 2013
let go
I can't help but giving out pieces of advice, probably a reminiscence from the times when I used to perform as a manager - yeah, I know what you think, hell of a coach, just an old fashion know-it-all manager. (Phew ... it's just struck me this bug of mine is what drove me to subconsciously start this blog!)
Anyway, today's advice goes to former software developers who embraced a management career and can't help but performing half of their time (they wish) as a developer and the other quarter (25% of time is wasted) as a manager.
LET GO! Just be a manager, your team needs you to take care of them, this is your most important task now! Why let go? Cause you can't afford it: besides the limitations that nature put on your intelligence, you are even more limiting yourself by focusing in two different directions.
Anyway, today's advice goes to former software developers who embraced a management career and can't help but performing half of their time (they wish) as a developer and the other quarter (25% of time is wasted) as a manager.
LET GO! Just be a manager, your team needs you to take care of them, this is your most important task now! Why let go? Cause you can't afford it: besides the limitations that nature put on your intelligence, you are even more limiting yourself by focusing in two different directions.
Thursday, February 7, 2013
easy svn merges?!?
Here is what you need to do to merge the changes from your long-living personal branch into trunk:
1. Back merge from trunk to your branch working copy
>>svn merge <svn_root_url>/trunk/<component>
2. Commit the branch working copy
>>svn commit -m "backmerge from trunk"
3. Reintegrate merge from branch to trunk working copy
>>svn merge --reintegrate <svn_root_url>/branches/<branch_name>/<component_name>
4. Commit the trunk working copy
>>svn commit -m "<meaningful message> ... <codereview url> ..."
5. Record-only merge to your branch so that you can continue using it
>>svn merge -c<revision_number_from_step_4> --record-only <svn_root_url>/trunk/<component_name>
6. Commit the merge from trunk
>>svn commit -m "record-only <rev_number> from trunk"
6. Commit the merge from trunk
>>svn commit -m "record-only <rev_number> from trunk"
Sunday, July 1, 2012
aesthetics
I believe in small increments: post a documentation bug here, correct a java doc or spelling error there, replace a Vector with an ArrayList when the collection is a local variable and you do not need synchronization, format a code paragraph. All this while marching on with your completely unrelated coding task.
Can't help it, but I always imagine a Grand Display, showing the product quality percentage, being run by a divine power that simply knows how to calculate it; and my change pushes that percentage up, indeed with a tiny increment, but still up, towards green.
Small and insignificant may they be, but the power of an entire crowd of developers doing small changes can be of a big importance to the product - a game changer long-term, for your next releases, for the maintainability of the product (something that the super power running the Grand Display did not teach us how to measure), because carefully crafted code and documentation will ask for code and documentation of the same quality level from the future commiters.
So encourage this practice to become contagious. Those that are likely to get infected first are those that can't help monitoring the source control commits. Don't think about your boss, but about the component owners with an interest in the component quality, the ambitious juniors that want to learn from others' code and those that want to make a name by finding other developers' bugs - all of them will appreciate your small increments.
Additionally, a trick to get more eyes to see your aesthetics changes is to include the files with small increments as part of the code review package for the bigger feature.
No, I am not preaching to occupy your time doing small changes - the vast majority of your time should go to changing the world. But big changes are never polished enough, so they will need the magic touch of small code increments.
Can't help it, but I always imagine a Grand Display, showing the product quality percentage, being run by a divine power that simply knows how to calculate it; and my change pushes that percentage up, indeed with a tiny increment, but still up, towards green.
So encourage this practice to become contagious. Those that are likely to get infected first are those that can't help monitoring the source control commits. Don't think about your boss, but about the component owners with an interest in the component quality, the ambitious juniors that want to learn from others' code and those that want to make a name by finding other developers' bugs - all of them will appreciate your small increments.
Additionally, a trick to get more eyes to see your aesthetics changes is to include the files with small increments as part of the code review package for the bigger feature.
No, I am not preaching to occupy your time doing small changes - the vast majority of your time should go to changing the world. But big changes are never polished enough, so they will need the magic touch of small code increments.
Tuesday, April 3, 2012
incredibly optimistic
Mgr_to_become_dev (MTBD): I see so much garbage around, that I become excited at the chance of cleaning it - I see opportunities to fix code and simplify everywhere.
Mgr_of_a_peer_mgr (MPM): yeah, it's so easy to do something and have a good impact.
MTBD: ... turning red into green.
MPM: I am the optimistic type, it is how I am, once I commit to something.
MTBD: I think there is no other way, after you rule out being neutral.
Now, press 1 if you think this is a real dialogue, press 2 if you think it is a cheap one stolen from "How to engage your employees" by Managers.
Mgr_of_a_peer_mgr (MPM): yeah, it's so easy to do something and have a good impact.
MTBD: ... turning red into green.
MPM: I am the optimistic type, it is how I am, once I commit to something.
MTBD: I think there is no other way, after you rule out being neutral.
Now, press 1 if you think this is a real dialogue, press 2 if you think it is a cheap one stolen from "How to engage your employees" by Managers.
Thursday, October 20, 2011
you on you
The painter in you will find the new canvas intimidating. The writer in you will find the blank sheet of paper intimidating.
The manager in you will find the immaculate-white background of the email client window intimidating ... it is supposed to hold the yearly evaluations of your directs, instead it's blank. Where to start you're asking?
Meet self evaluations: I am finding them to be the easiest way to kick off the employee evaluation process. Is it as simple as you asking your directs for their own perspective on their accomplishments, contributions but also on unmet goals and targets over the past year. (in the Romanian immature corporate culture we sometimes call the latter bad things).
Give them time to think.
Then add your own observations - you should have observed them and taken notes throughout the year. Then add the others' feedback to the mix: team members, customers, other managers that happened to interact with your guy. Then look for some facts, in your project plan, bug tracker, emails, reviews.
That's it ... fully armed now to conquer that white background!
The manager in you will find the immaculate-white background of the email client window intimidating ... it is supposed to hold the yearly evaluations of your directs, instead it's blank. Where to start you're asking?
Meet self evaluations: I am finding them to be the easiest way to kick off the employee evaluation process. Is it as simple as you asking your directs for their own perspective on their accomplishments, contributions but also on unmet goals and targets over the past year. (in the Romanian immature corporate culture we sometimes call the latter bad things).
Give them time to think.
Then add your own observations - you should have observed them and taken notes throughout the year. Then add the others' feedback to the mix: team members, customers, other managers that happened to interact with your guy. Then look for some facts, in your project plan, bug tracker, emails, reviews.
That's it ... fully armed now to conquer that white background!
Wednesday, August 17, 2011
one team for the customer
What have you done lately to make your customers happier?
Have you called them more often? Have you stopped developing new features until you reach a Zero Known Bugs state? Did you hire the best Information Engineers to make your docs all bright and shinny?
If a lot more than this, or none, or none of the above, let me give you another idea of what we do:
We built a cross-feature team staffed with the brightest people who analyze customer escalations, observe trends and write beautiful code to make sure future escalations in the area are near to impossible. Out of 30 customer escalations on how slow your server compliance checking runs, they would come up with a new way to access your compliance rule repository using a proven web server instead of your custom (slow!) python multi-threaded code.
How would this setup work? Would they sprint together with the rest of the teams? When will they sync with the feature teams to make sure they are not writing the same optimizations? Would you have this team on a permanent basis or build it ad-hoc depending on the number of current escalations?
Know what, these are all up to you, in the end it's the client 'smile' that matters.
Have you called them more often? Have you stopped developing new features until you reach a Zero Known Bugs state? Did you hire the best Information Engineers to make your docs all bright and shinny?
If a lot more than this, or none, or none of the above, let me give you another idea of what we do:
We built a cross-feature team staffed with the brightest people who analyze customer escalations, observe trends and write beautiful code to make sure future escalations in the area are near to impossible. Out of 30 customer escalations on how slow your server compliance checking runs, they would come up with a new way to access your compliance rule repository using a proven web server instead of your custom (slow!) python multi-threaded code.
How would this setup work? Would they sprint together with the rest of the teams? When will they sync with the feature teams to make sure they are not writing the same optimizations? Would you have this team on a permanent basis or build it ad-hoc depending on the number of current escalations?
Know what, these are all up to you, in the end it's the client 'smile' that matters.
Monday, June 13, 2011
replacing technology <T>
- never heard of T, is it software?
- sure I've heard of it
- I'm a big fan
- tried it in a Hello World
- use T daily
- reported a few bugs
- contributed to the code base
- I am T expert consultant
- I developed a parallel technology
- it's history, my technology simply wiped T out of the market
- What do people say about your pet project?
- Don't have a pet project?!
- Are you a software engineer?!
- ... um, never heard of you, sorry.
- sure I've heard of it
- I'm a big fan
- tried it in a Hello World
- use T daily
- reported a few bugs
- contributed to the code base
- I am T expert consultant
- I developed a parallel technology
- it's history, my technology simply wiped T out of the market
- What do people say about your pet project?
- Don't have a pet project?!
- Are you a software engineer?!
- ... um, never heard of you, sorry.
Saturday, May 21, 2011
satisfaction
It is a few months before a new Server Automation major release ships, so it's time to let the customers take a peek at what we've been working at in the last 6 months. We are taking them on a test-drive (but don't let them in the driver's seat yet) of the new features to get them to comment, like:) or dislike:( them.
But we got more than this in the last demo. The client was so pleased with the features we developed that this got them into a chatting mood, so some of us ended up pouring questions onto the client about their environment, how they use the product for their use-cases, how they horizontally scale their work (or not) when dealing with tens or hundreds of servers. It won't be far from the truth if I said that our questions outnumbered the client's. So yes, we got something extra out of it.
And the client got something extra too: as the discussion developed, they got their share of answers and tricks about the old features they've been using for a while now.
Still, we got more than the client did: satisfaction. Satisfaction cause they were satisfied. And it was plenty of it to share, to the QA eng that did the demo cause his clicks unveiled the magic, to the functional architect who spec'ed out the magic and for the handful of developers that ... built the magic.
Are you feeling down? Ask your customer to come in for a demo!
But we got more than this in the last demo. The client was so pleased with the features we developed that this got them into a chatting mood, so some of us ended up pouring questions onto the client about their environment, how they use the product for their use-cases, how they horizontally scale their work (or not) when dealing with tens or hundreds of servers. It won't be far from the truth if I said that our questions outnumbered the client's. So yes, we got something extra out of it.
And the client got something extra too: as the discussion developed, they got their share of answers and tricks about the old features they've been using for a while now.
Still, we got more than the client did: satisfaction. Satisfaction cause they were satisfied. And it was plenty of it to share, to the QA eng that did the demo cause his clicks unveiled the magic, to the functional architect who spec'ed out the magic and for the handful of developers that ... built the magic.
Are you feeling down? Ask your customer to come in for a demo!
Subscribe to:
Posts (Atom)
