tablet

The point is nobody destructs nothing. There are various tools for various purposes.

We had 40-hrs work week rule from day 1 (well, nobody followed it in the beginning though). Now we have 50 people on board and it is really important to maintain a good balance to keep energy. So we have 4 working days and 1 day (Friday) dedicated to learning and personal projects. We have no overtimes for years. It is an incredibly rare event.

Nothing distracts good developers to write good code. There is NO excuses. Bad management? Bad mood? Fuck it. Find another job if management can't live with good solutions. Again. No excuses.

I believe the resulting situation is not what you should blame agile for. Shitty code created by shitty developers. No exceptions.

Thanks, I've tried my best :)

I think every good parody has some truth.

Huge companies are interesting. I think Google is closer to fox now. It closed down quite many products and focused on several (search, android, docs).

Maybe Fox/Hedgehog caregorization is not applicable to such huge companies. Most likely there are departments and products where foxes are in charge and vise versa.

Internet is improving. UNIX is improving -> Linux, etc. LISP? I'm not sure whether it still alive.

You define iterations like something small. In general, iteration can mean something huge, like full re-work.

I mean, improvements can be gradual or revolutionary. Still it is iterative process.

It's a very, very bad re-design. - Grid is hard to track and keep an eye on. You will constantly lose information and get frustrated pretty quickly - Long comments with 20 words per-line is bad for reading. You will have hard time jumping to the new line. - Navigation is quite complex and will turn many new users down. It is good for experience users though. - In reality you will not have such nice videos and photos. So it is quite artificial.

BTW, Valve has similar bossless culture. http://www.quora.com/Valve-Corporation/Does-Valves-employee-...

So far it looks to me like a living example to learn from.

Outstanding CEO, cool culture and organisational principles.

1. I don't think people will pay for that 2. I don't think there will be enough users to decide how to monetize later.

I can speak from my voice only and I won't use such service.

Thank you! Great hints. We gather enough evidence to remove second page and do some other changes.

Thanks. That is very helpful!

I use http://shelfari.com

It is quite good, integrated with Amazon and even provides some stats.

Yeah, we had some discussion about 2nd page and some people suggested to remove it.

Well, now it goes up...

Here is the story. Initially Python was used to simplify, automate and speed-up REST services testing. It appeared, that scripting language is a perfect fit for DSL we want to create. DSL I'm talking about serves several goals to end users:

- Filter anything. Like get all work assigned to у AssignedUser.Contains(Me)

- Add entities into system quickly

- Do batch operations on entities. Like movetoproject('45')

- Define own macros and use them (VERY advanced feature)

def rejectIdea(e):

e.entityState = 'Closed'

e.comments = [comment('Sorry, we are not going to implement this idea in the future')]

e.save()

Basically, I am speaking about CLI (with autocompletion) for end user. It is VERY uncommon for web application to have CLI, but I personally think it is a killer feature to advanced users who wants to be really productive with the system. Python is used to create and engine for all these operations I've described above. In future end users will be able to program own behavior. Sounds a bit crazy, but still it is worth to try :)

We have a discussion with every employee each 6 months. This discussion is open and we chat about topics that were learned, knowledge that was improved, etc. This affects salary rise (as well as good performance overall).

Thank you!

> 10-11)

Yes. However, daily releases are possible for SaaS solution only.

> 12) Are release and eventually rollback operations automated just like a one-click operations and so are the deploy to the automatic test servers?

Yes, deployment is automatic. Roll-back is semi-automatic so far, but we are working on fully automatic roll-back and it will be ready soon (for SaaS). However, customers can install TargetProcess on their own servers, and in this case there is no automatic roll-back.

> 13) Can teams make architectural changes (i.e. change the persistence technology, change the presentation technology, change the authentication method/technology, change the caching or session state implementation) comfortably and gradually and without pain or huge risks ?

UI layer - yes. Caches and persistence layer, not so easily. Codebase is 8 years old in some places and definitely there are parts that are hard to modify. Several years ago speed was more important than code quality, so we have dome debts to pay. New code is very clean and cool, old parts of the system refactored gradually.

> 14) When you removed the time-boxing and at the same time adopted some kanban practices (from the report I understood WIP, leading time, just-in-time meetings as retrospective and planning) have you considered the possibility to keep both (as I understood time-box and kanban practices are compatible and so kanban and meeting with a fixed cadence are compatible, so as I understand all are valid options that team can adopt) ? What teams sensed in order to make the decisions and what consequences have observed ?

The main reason to try Kanban was an ability to release each feature or bug fix separately, so we did not considered cadence of any kind. I don't think cadence is required in Kanban. But definitely team can keep it and see how it goes. Changes were not easy initially, but in 2-3 months situation improved and it was clear that Kanban works better for us.

Wow, thank you for so many questions :)

1) How often teams released in each of the 4 years

We release new builds every other week. Sometimes more often, sometimes less often, but on average every other week.

2) What is the state of the code-base (i.e. how many parts of the code devs would prefer not to work with, how many bugs are discovered only in production, what is the CC, what is the size of the longest method/class, how many conditionals and static members are in the code, how much time it take for a new team member to do it's first check-in)

Code-base is quite good. There are some parts that are complex (like custom reports), but in general nothing is so bad that anybody hates to touch it. I can't provide any metrics on method/class/static members so far, will try to gather them soon. Usually it takes 1-2 days for newcomer to dig into codebase and start bug fixing.

3) What about collective code ownership ?

There are no owners. Sure, some people are more fluent on some areas, but everybody can change everything.

4) How many time you discovered/learned things only after releasing a feature and how are you dealing with that now

There were 2 major fails last year. One caused by missed requirements in Subversion integration plugin and another one due to critical bug found on production. That is quite rare cases. Sometimes bugs indeed come from production, but most of them are minor. Our testing process is good enough now to catch almost all critical bugs.

5) How much unknowns, uncertainties, unexpected-unpredictable events and changes there are in your domain and business and how you deal with them

Well, agile domain is quite fluid. But there is no immediate changes. In general we should react every year on latest trends in agile domain.

6) What about devops and support and operation of the system in production?

We have a dedicated support team (4 people) and 1 developer almost fully dedicated to support issues. Other developers help customers as well when required. We provide live chat support, email support and live skype sessions support when required. Support team is really responsive and to be honest that is one thing I proud of.

7) what about the features released, how much they are the right features for the users and for the stakeholders ? how much early the team spot the wrong feature?

We don't have stakeholders, only end users. Product vision comes from various sources, mainly from customers requests. However, we do not implement requests blindly, but try to find root solution. Last year we released only useful features, all of them are used by customers. Previously there were quite many mistakes and software started to bloat. We cut some features off and now are very careful with new functionality.

When we started a product, we agreed to split shares according time spent on the product. For example, I worked about 40 hrs per week (we all had another (main) job initially), but other 3 people worked ~10 hrs per week. So in the end I had higher stake.

If you both work full-time, this strategy will not help. However, you can find a measure of value. Maybe your partner is good at something else, like promotion and marketing. Then you should discuss responsibilities and maybe he can do some smaller features, but will focus on something else. If that will not work, I think you just can't keep work together, that will be a waste of time and a road to failure.

1 there are many book on creativity techniques, you can find many of them in the web. I can recommend Thinkertoys: a handbook on creative-thinking techniques. Business Model Generation is also a good one.

2 get the idea and start as early as possible. Don't waste much time on idea generation, a month or two will be enough. When you start, you will learn. And knowledge is the most valuable thing in your first product. Be ready to start over with new skills and wisdom. But it may happen that the first idea will bring good revenue. Be ready for that as well :)

3 I like Steve Jobs. From what I read his thinking style is cool.

There is one outstanding hacker in our company. He is one of the smartest people I've met. He knows so much and incredibly deep. However, he has no blog. He has no github account. He does not share own code anywhere. He does not use social networks. Your advices quite correct, but quite dangerous at the same time. I learned that CV are often misleading, so better to contact a person and ask some questions...

I see. It can be added on mouse over, similar to vote up action.

What is "flag" functionality?

Do > tell

Write > read

Think > speak

Left side matters more

I use ReadLater - it is the best way to save interesting articles and read them anywhere Flipboard and Zite - for random content

However, it is much better to read Books, not articles...