Posts Tagged Teams
Continuous delivery implementations differ due to company testing culture
Posted by Morten in Uncategorized on July 25, 2011
I just finished reading a post about continuous delivery at Outbrain. It’s quite interesting they made a trip similar to what we have done at RemoteX. However their setup is some what different than in the our. They use a tool called Glu to do deploy to the their different target environments and deliver RPM’s for their services.
At RemoteX we produce .exe files as well as a set of web services so I guess there will be significant differences when looking at the actual deployment.
What I find interesting is that they seem to go directly from the builds in TeamCity to starting deployment, where we at RemoteX have several steps after the commit stage to package and verify our release before its pushed out.
Outbrain also seems to be able to target specific environments to deploy to in a greater extent than we do at RemoteX. At RemoteX we instead categories our system installations to gradually deploy to all our installations.
This brings up something that seems to be common when reading Continuous Delivery war stories. They all agree (mostly) what what Continuous Delivery is all about, but they all implement it differently and have different areas where the solution is stronger or weaker.
The pattern seems to be that once the product goes out to customers there are different cultures at the companies that requires different solutions. The example of deploying to specific environments or deploy to categories of customers for example.
These cultural differences seem to all be focused around faith in the quality of the product. With in turn boils down to faith and investment in automated testing vs. manual testing.
In theory it would be possible to see what the culture at a company is like regarding to their faith in their own deliverables, by looking at their continuous delivery solution.
Development as a team or development as stars?
Posted by Morten in Uncategorized on May 23, 2011
A good friend and colleague of mine Johan Andersson read somewhere that you can see the communication patterns of a company in the architecture. I can see how that makes sense, but I think its much clearer than that. I think you can see the communication patterns of a company in the interface of its products. Both API’s and UI.
Every bump in the flow of a product, every view that is different from the main theme, every glitch in the feel of the application. They all show where a Star has solved a problem. They all show where communication failed and brute force problem solving stepped in to save the day.
An example could be an integration that uses a mostly unused field to store some information that it was not meant to store. Such as dates being printed in a text-field. Or having to leave the application to complete parts of the workflow on a webpage (or on a different site).
If we consider an application and its features as an onion. At the heart of every application there is a core functionality, the minimum viable product. On this other features evolve, or are developed. In essence making it a bigger onion for every aspect covered.
It could look something like this:
 |
 |
| Teamwork feature circle | Star work feature circle |
Now let each layer be complete, if the workflow of the feature is complete. A layer is incomplete i.e. graphed, if they break the flow of the product in order to solve a problem. If they just add enough functionality so it solves the task at hand.
Naturally these describe the wholeness of the experience, and is not tied to the implementation in any other way other than the feeling one gets when using the product. A product developed with good teamwork feels whole and complete around each feature. A product developed with individual stars will still solve the task at hand, but the experience of using it is scattered and lacks flow.
Is this bad?
Pros
- The problem was solved
- Functionality is implemented as the customers wish
- A sale was hopefully made, money was gained
- It might have gone faster due to reduced communication costs
Cons
- There is a glitch in the workflow of the application
- Something looks astray if you consider the whole
- There is a severe risk of bugs being introduced at a later stage, due to things not working as expected
- It might cause rework to repair the flow, or fix the later introduced errors
These lists are probably longer, but they show the pattern
Let’s look at this from a sales perspective. If your method of selling is by listing features and selling a complete system, the stars approach is desirable, it will give you a list of features quickly. At the risk of the development going slower further down the road, especially if you build on “previous” features.
If you, however, sell by demos or free trials, showing the experience of the product and how convenient it is while solving the problem. Working with previous customers who testify to the product’s stability and trustworthiness. The teamwork approach will most likely give you the best experience, and reduced amount of bugs. Thus it might go faster in the long run.
From a buyers perspective, I’d rather use a product with complete flows.
Now ask yourself, are you a star or are you a team member?
How does your organization sell its products? Does selling like that benefit Star development or Team development?
What benefits your organization most? Teamwork or stars?
A pull process
Posted by Morten in Uncategorized on November 22, 2010
While reading The Power Of Pull, I came to think about push and pull processes. Now the definition of these is not the same as a push or pull process as used in that of lean processes, instead here a pull process regards an open platform on which participants can pull information from and add information too.
In essence an open-source project is often a pull platform, where people can access value from, attract more people willing to add value and achieve new value through the combination of new ideas.
So as I was reading I began thinking of how to build a pull platform for a company. Most companies are push processes, where a tight group pushes the organization in a direction the group wishes. A pull process instead allows the people in the organization to react to new ideas.
Now Scrum is in a way a push process, the prioritizing and decisions on What to do is done by the PO. How would a team process look like if it instead was a pull process? A process where you attract, access and achieve. Where the contribution of the individuals decide the trajectory of the value generation. Instead of a governing Product Owner who points in the direction the product should move.
How does the concept of profit work in this scenario? The normal approach to payment probably will not work as you want to attract a wide amount of inspired people. Money might be limited, and typically traditional payment methods imply a push model. Since you want to send your money to just one person. The distribution of payment should be handled in the pull platform.
Naturally the resulting product should be open for contribution and or extension somehow.
Just some thoughts for now.
My presentation at AS2010
Posted by Morten in Uncategorized on May 15, 2010
I held a presentation at AS2010 about handling defects. The slides are up, unfortunately there is not text in the slides and there’s no audio track… but for those who wish to see my slides you can find the at:
Inventory in software
Posted by Morten in Uncategorized on May 5, 2010
I’ve been thinking a bit about all these factory references that occur when discussing software development. So here is an inventory management view, I guess.
Inventory, viewed from a lean perspective is waste. If you can keep your process running with minimal inventory, then you can decrease costs for changing the process.
Software is immaterial, so there is no “inventory” per se. But, there are equivalent cost scenarios.
Here are a few examples of inventories that occur during software development:
- Documentation
- Versions of the same software in production
- Source-code
- Issue tracking systems
I’ll describe the cost scenarios for these examples, there is probably more.
Documentation
As soon as you write your documentation, it starts aging. Documentation, be it help documents or documents describing the system, are like groceries. They go old, and they do so in different rates. Some documentation is more resistant to change while other gets outdate faster than you can write it. This implies a maintenance cost for documentation, either keep it up to date or throw it out. The cost of someone using old documentation could be very expensive.
Versions of the same software in production
A favorite of mine. Every version you have in production has its own personality, it’s own quirks, features, bugs and what not. This implies greatly increased support costs.
Source-code
Source-code is also a sort of inventory. The more code there is the more there is to maintain. Sure you might not change the code all that often, but unless your code is separate products, it interacts. Larger code-bases require more testing (be it automated or manual testing). Good design helps reduce the size of the code base, and from a cost perspective keeping the codebase low is very important.
Issue tracking systems
Issue tracking systems is just an inventory of reported issues. As it grows the cost for maintaining the issues grows. Every release has the potential to solve any issue, which could at worst imply workload on developers to keep, not only the source-code and documentation up to date, but also the issue tracking system. Secondly, if it takes too long between something being entered into the tracking system and it being fixed. Then the people, stakeholders, for that issue have forgotten about it or worked around it in some way. Also most of the time, the act of managing and tracking the issue costs far more than just fixing it.
Reducing inventory
So what to strive for, only keep documentation for which you commit to writing and maintaining. Have one version of the system in production, and get mechanisms into place to quickly update all clients so you can keep it so. Keep your code-base small, strive to solve problems using better design and less code. Think more, code less. Last but not least, fix problems as they occur, strive for zero-defects. If your using Scrum you can handle issues in a sprint, but avoid long-running tracking.
How you write code is a habit
Posted by Morten in Uncategorized on December 10, 2009
These last couple of days we have been having a internal TDD course at RemoteX. We had the help of Andreas Brink, whom guided us in testing and over all code quality.
One of the things I noticed during the course is how heavily influenced I was by old habits. We’ve been doing testing for a while, and fallen into the habit of isolating everything using mocks.
One of the things I learned this last week is that mocking is a great tool, but shouldn’t be used as intensely as we have. When pointed out to us we noticed that the way we used mocking actually introduced more code in the tests than we had to.
The order of setting up and doing assertion’s was often distorted since the mocks didn’t have state. Expect calls for example are typically set up in the beginning of the tests, but checked after. Meaning that the verify code is at a different location than the code saying what is verified. End result, the tests aren’t as clear as they could be.
But the influence of habit doesn’t stop there. Details such as how much you use the mouse or keyboard, or utilize the tools available are all depending on your habit for writing code.
For example I have a colleague who knows the keyboard shortcuts, but has the habit of using the mouse. This habit is so heavily indoctrinate that when he is on a laptop, he reaches for the touchpad instead of using the shortcut. The touchpad on my laptop has low sensitivity so the time to write code is heavily hit every time you reach for it.
Hard part is to notice your own habits, some are good, some are bad. Both are good to be aware of.
Understanding code
Posted by Morten in Uncategorized on December 8, 2009
“I can look at code and understand it but i cant write code”
There seems to be a common misunderstanding that if you can read code and “understand what it does” you understand the code. I’m sorry, If you cant write the code yourself, you do not understand the code.
Being able to read code doesn’t mean you understand it. Anything can hide in those pretty method names.
I write laws
Posted by Morten in Uncategorized on October 19, 2009
I went through a business contract, analysing it for weaknesses. I found a not likely case, but still pointed it out.
“You should be a lawyer”, the lawyer says
“I write laws”, I reply.
Now why am I writing this?
Well, there are similarities to developing Laws and developing business systems. Laws are rules in which we humans can work within to achieve value. The value Laws strive for is the value of functional society, a functioning system.
Now developing business software can be viewed in the same way. When developing the software we state the laws in which the users can generate data. The UI is a constraint or law, the business rules are different kinds of laws, and so on. The value we strive for is correct business data, another kind of functioning system.
How it is to live under these governing systems i based on the values they are built upon. A Mac user have different values regarding usability, design, and in some cases “quality” – compared to a Windows user.
Developing software is a team effort. The development team are the legislators of the product they are developing, so which values are governing your software?
Tooling idea for Getting things done with teams
Posted by Morten in Uncategorized on September 11, 2009
Roughly 1½ year ago I produce a plugin for team-system to allow me to report bugs quickly though as I’m working with the code. The idea behind it was from the Fogbugz intoruction video where I think its Joel Spolsky who says something along the lines of “it should take less than 30 seconds to report a bug, else the lazy developer wont do it.”
The resulting plugin was a short-command that started up a UI with a single textbox on it. I wrote the “bug”, and it created an bug item in Team System with my specified title. It also made sure to “record” the context of where I was in the code when I wrote the item. In this case, file and line-number.
In a previous post I discussed how to get things done with teams.
Consider having such a plugin to your IDE that will report the item generated to a central inbox, central for all developers. The item could be a bug, it could also be a suggestion for refactoring, request for more tests, idea for a new feature and much much more.
With such tooling in place, a team could quickly shed some light on issues that aren’t directly related for the delivery of the current iteration. But more related on the values of the team or the ongoing quality of the code product. The issues can be reviewed and managed during a weekly meeting, resulting in product backlog items, sprint backlog items, discussions, meetings. Or just a sense of common values within the team.
How I work with code the unit test part
Posted by Morten in Uncategorized on September 10, 2009
I wrote a blog post about how I work with code. The basic idea is that I record actions that I need to take as I work with the code in a format that is readable by the other developers in my team. In case I get run over by a truck they can see where I took off. Also its a way to record what and why I’m doing as I’m progressing through code written by someone else.
I got a response from a former colleague Anna who claimed I wouldn’t need to do it if I had automated tests. Even though Automated tests doesn’t have much to do with personal productivity at first glance, a recording of something that needs to be fixed could be a unit test. If developers run the tests often they are in my shelveset and they can see which pieces of the code I perceive bugs in.
In fact this is exactly what is being done as I work with TDD. Giving support to the fact that TDD can increase the productivity of a developer, following the same ideas presented in Getting Things Done.
Tests however doesn’t record suggestions for design improvements or actions such as “Ask x about icon y”. At Least not as far as I know.