Mumboe is now on GitHub

During development of the Mumboe Contract Management product we have created and modified several open source Ruby gems and Rails plug-ins. While that code has been on GitHub, it has been managed under individual developer’s private accounts. We have now consolidated development under a single Mumboe account for all of our open source projects. The Mumboe GitHub user currently hosts our forks of:

• aasm Fork of the acts_as_state_machine (AASM) gem. The fork adds support for logging state changes in a DRY way.
• amatch Fork of the Approximate string matching gem. This fork incorporates Michal Granger’s Ruby 1.9 patch
• has_easy Easy access and creation of “has many” relationships for ActiveRecord models. Forked to fix some bugs around validation errors.
• param_protected A Rails plug-in that provides param_protected and param_accessible methods on controllers. This fork allows the use of a Proc for generating the action list in include/exclude from protection.
• soap4r Modified soap4r library to run on Ruby 1.9

Add comment June 24th, 2009 Author: ScottD

FineTooth at AMIA

FineTooth will be at the AMIA 2006 Symposium for a poster presentation with the Fred Hutchinson Cancer Research Center. The presentation is on the use of our automated text extraction service to build a cancer tumor registry from pathology reports. The poster presentation is part of S13 Poster Session 1. If you are going to AMIA this year stop by and say hi. If you can’t make it here is a link to a PDF of the poster. Please note the real poster is 4 feet high and 8 feet wide, so the file is large.

Add comment November 8th, 2006 Author: ScottD

Job Openning at Finetooth

We are in the hunt for another UI developer for our contract management web application. If you are in the market or know someone who is, shoot them the job info. Here is a repost of the information from our corporate site:

Senior UI Developer

FineTooth is currently seeking a Senior UI Developer to join our team and contribute to the front end development of our web based, scalable, on demand applications. Working together with a small team of web and database developers in an agile environment, the Senior UI Developer will have the opportunity to develop and gain experience in a fun, fast-paced, and flexible environment.

Qualifications:

• 4+ years experience in UI development, preferably with scalable production web applications
• Strong experience with HTML, CSS, JavaScript and AJAX programming patterns
• Experience with PHP and XML
• Familiarity with graphic design and associated tools including Photoshop and Illustrator
• Good sense of usability in graphical UI design running on real time systems
• Ability to work both independently and as a member of a small team
• Desire to work in a fast-paced, fun, and flexible environment with great benefits, developing cutting edge technologies
• Undergraduate degree or equivalent years of industry work experience

Applicants are encouraged to provide examples of past UI development work or sample applications that demonstrate UI and software engineering skills.

For immediate consideration, please send a word doc resume to careers@finetooth.com with “Senior UI Developer” in the subject line.

Add comment November 6th, 2006 Author: ScottD

Ad-Hoc teams for Agile Development

As a company that is working on implementing the Agile process to develop a product aimed in the enterprise space, I have been very interested by the series of posts from RedMonk’s Michael Cote called “Agile in the Enterprise”. His comments and the problems of implementing Agile with large teams got me thinking. He mentioned the practice of having “Scrum-of-Scrums”. He mentions that coordinating all those small teams and keeping everyone pointed in the same direction is difficult. I think one of the problems comes from the structure of teams in large software shops.

Traditionally teams are divided by areas that match up to the architecture of the technology. So you would have a “UI” team and a “Repository” team and an “API” team, etc. This kind of division creates silos of expertise and responsibility that are an anathema to the Agile process.

For one, this break up harms the open communication upon which Agile depends. The channels of communication between teams in a large company are not going to be as open and responsive as those within the smaller group. Teams are placed in different areas of the company, sometimes on different floors or buildings, or worst yet cities. If a developer from the UI team has a problem with some new feature that interacts with the reporting engine, how long is it going to take to get an answer/solution when the report engine team in located in a different building instead of the next room?

Also, new features rarely rest in a single part of a system. This forces the work of a story card to be divided among several teams with different priorities and team leads. The coordination for this division is supposed to take place during the Scrum-of-Scrums. But each group will prioritize its own work to meet its own deliverables. This could create delays and conflicts between groups.

Finally, I think the break up of expertise and responsibility amongst teams will harm the clean and refactoring of the system. In Agile you are supposed to constantly be refactoring to clean up cruft in the system and improve its implementation or design. But if you only have access to or knowledge of small segments of a larger system how confident are you on the repercussions of your changes? And if the one team spots a change to be made in another part of the system can they make the change or does it get scheduled for the next sprint?

Ad-Hoc Teams

An idea I was mulling over, and I don’t think it is probably unique, is to create teams in an ad-hoc fashion. At a large development shop there would be a pool of team leads and a pool of developers. At the start of a sprint teams would be formed based on the work to be preformed. Each group would contain the developers and expertise necessary to complete the story cards they were assigned. If the cards require 2 UI guys and 1 DBA, fine. If it requires only developers that know the repository engine, fine.

The processed use to form these groups at the start of a sprint can be as formal as the business requires. You could get all the leads in a room and have them divide the work and then chose which developers would be best for each team. You could also have a more democratic method of all the developers choosing there own teams as you go through the cards. You can try and have people rate which features they would like to work on in the next release and then try and best match those preferences. I think the method used depends a lot on the personalities of the people involved and how they interact. Results for each may vary and it is a process that I think would have to be tuned for the first couple of sprints. The only process I would avoid is the having the team leads pick people in a round robin type fashion. A little too much like the schoolyard playground. Too many painful memories for most programmers about being picked last every time for baseball even though you know you are better then Stevie. But I digress into my own childhood issues.

The important part is that you want people overtime to work with different teams and in different parts of the system. This will improve everyone’s knowledge of the system. It will also give everyone a chance to work with everyone else. I think overtime this will make the teams more productive and estimates more reliable.

These ad-hoc teams could also give a company the opportunity to try a lot of flex space solutions. Do the ad-hoc team members move every sprint to a new location? If so what kind of office space do they have? One war room or cubicle area per team? What kind of IT and building management issues can this cause? If you don’t relocate people for each sprint how do you create open communication channels for the new team? Also, would not moving people create pressure to put people that are already located together in the same team? This would scuttle the idea of having people move through teams. I know some companies that are very successful and have developers living in different cities but still work closely with each other. IM, email, Skype, and monitor sharing software may be the answer for this.

FineTooth currently has a small development team and we haven’t had to worry about these issues yet. But as we grow as a company the problem of keeping a fast, agile small company approach is on my mind. I would like to hear what other people are doing, or not doing and their experience. I would especially like to hear about people who have worked for companies that have transitioned from 5-10 developers to 20+.

Add comment March 17th, 2006 Author: ScottD

Welcome

Add comment January 10th, 2006 Author: ScottD