Matthew Botos

DIY Photography is giving away a few copies of Portrait Professional as prizes in a portrait contest, so I decided to take a look at a demo of the software. I find myself doing more with Aperture’s retouch and clone tools and was curious if this would be a more automated way of cleaning up wrinkles, imperfections, and the circles under the eyes everyone seems to be sporting today.

Portrait Professional is different in that it’s not a localized retouching tool, but rather one for global enhancement based on a training set of beauty images. (The former artificial intelligence student in me wonders what kind of neural network or other training system they use.) You define key points on the face (eyes, nose, mouth), and it maps the enhancements onto them. The various changes are adjustable, and they also have localized tools for fine-tuning.

(more…)

I’ve always been a big fan of making the computer do the arduous part of the work so I can concentrate on the more interesting parts. When writing software, that’s generally meant relying on terse or sophisticated languages like Perl and Matlab. I’m currently taking it to the next level, though, by using code-generation tool and frameworks to generate complete code layers with full unit tests.

(more…)

You can now search by multiple tags in my photo gallery! (Since spaces are usually allowed in tags, the whole search was previously treated as one tag.) If you’d like to add this feature to your own Gallery2 installation, replace TagsSearch.class with the file in this zip:

Download Multi-Tag Search for Gallery2

Code reviews are another software practice it’s tough to buy into until you see the value - which has recently become apparent to me after finding a very effective way of doing them with a number of added benefits.

I discovered this through an unintentional experiment: after having a single person review a new piece of code, we sat the whole team down and a walk through of the same code. Together we exposed many more opportunities for improvement, and started a lot of good discussions on standards, reuse, and code quality. That continued this week, where we found that even that “peer-tested” and  “done” code still needed some fixes.

Another benefit was that it gave everyone a chance to see other parts of the system; that kind of cross-training makes a team much more flexible and resilient to turnover and absences. It’s also a nice chance for people to show off work that would otherwise stay in the dark. Overall, though, I think what really impressed me was how much a review by the entire team encouraged conversation and put quality in the spotlight.

The problem with a lot of new ideas, particularly software development methodologies and management trends, is separating the wheat from the chaff. Until recently, test driven development was another bit of hype I didn’t buy, but I few recent experiences have changed my mind to the point where I’m actually using it at home on personal projects.

What really made a difference was seeing it in action: writing a test, writing some code, and seeing that it really worked. Repeat that for a number of scenarios and you start to feel pretty good that what you have is solid and you’ll know if you break it in the future.

The second feature is that someone sold me on what it could do for me as a developer - free me from the tedious, ad-hoc, labor-intensive testing process that tends to go along with my rapid style of development. At work, it’s allowed me to bypass all the clicks of a web application to test the underlying logic, and at home I can test my photo management scripts without manually shuffling around files to be modified.

The real test of my commitment and realization of its value will probably come the next time I modify Gallery, a very large PHP photo gallery with an equally large testing suite.

Almost as soon as I mused on What I Want to Be When I Grow Up, one of those paths found me. After a week of scrum training, my manager did a quick, quiet poll of the team, and ratified their vote for me as scrum master.

The fact that this was largely peer-driven makes it a bit more meaningful; certain skills are often only truly appreciated by other techies, and it’s nice that they trust me to keep management from meddling too much with their day to day development activities. It also plays to my desire to have a broader view and influence in the projects I work, and the provides the enjoyment that comes from mentoring in various forms.

My concern of losing hands-on technology time has only partially been realized; I’m still being tapped for some development work, though administrative matters seem to be consuming most of my time. It’s exciting to see the project really start rolling with scrum, and I’m much more engaged now that I have some skin in the game.

We’re doing a week of agile, scrum, and associated tool training at work this week for our whole team, and it’s really eye opening. As I mentioned before, despite a year’s experience with all of this, I’ve always seen it colored though other’s eyes and modified implementations.

At its core, most of it has nothing to do with software development or manufacturing, but just communication in general. Communication amongst a team, with their customers & users, and with the other stakeholders in a project. It’s a basic element, but one that easily becomes ignored or overly virtualized, losing the most valuable type of communication: face-to-face discussion. A good proof is that people use these methods for running a variety of non-technical projects and they do it with technology as simple as index cards and post-it notes.

Respect - and trust - are other core values. Businesses tends to treat people as resources, and get similarly unimpassioned work in return. Treating people as full members of a team with a stake and say in the project’s outcome has more than doubled productivity and quality for those who are willing to make a leap. And it is quite a leap: let a self-organizing team run their own work, replace a hierarchy of team leads with scrum masters who serve the team by removing impediments to facilitate work, and give the team the power to select and dismiss that person as necessary.

It’s a big cultural change to sell and execute, but given that “culture eats strategy for breakfast”, it offers potential for truly effective increases in productivity, quality, and morale.

I came across A Resuable Presentation on Scrum this week while looking for materials to help explain this method of agile software development to a colleague. In the process, I also got an education - on how much the scrum projects I’ve contributed to over the last year have varied from the “pure” ideal.

It’s partially due to the tendency of many companies to adopt scrum in a modified format. Such customization is surely necessary for the variety of businesses that write software, though it sometimes misses key points. In particular, it’s tough to institute scrum without creating another hierarchy in organizations both large and small. Without a flat, peer-oriented structure, projects miss out on the quality and morale benefits of developers having some choice and ownership in their work.

On the other hand, it was good to see that most of the key roles and rhythms manifested themselves in some way. An interesting tangent also came up in our discussion: that while scrum dictates methodology rather than technology, it does influence the latter. To do monthly releases, you really do need to have efficient tools for development, compiling, and testing software.

Ultimately, it was a reminder that no matter how you develop software, there’s as much social engineering to be done as technical engineering.