Category: Software Development Best Practices

Who values your product and do you value them?

Michael Walkden, Friday, March 12, 2010 @ 11:26 am

photo credit: victoriapeckham

We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times...

The easy part is over. Now the hard part begins.

Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:

• What customer group do we value the most?
• What features do they value the most?
• How expensive is it to build the ultimate product for each group?
• What is the minimum viable product we can build for each group?
• Which group is most likely to give feedback and partner with us to help refine our product?
• How much feedback is this group likely to give you?
• Are we missing some market window by passing on one group v.s. another?

This is a critical point in the product's design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren't likely to be interested because we aren't building any features for them yet.

When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Refactoring versus Rewriting

Dietrich Kappe, Monday, March 1, 2010 @ 5:09 am

photo credit: moonlightbulb

I started my first real Agile software development project in 1999. I'd been doing more traditional software development before then all the way back to 1980. I won't bore you with the details of those earlier projects, but my feeling was that there had to be a better way of developing software that didn't involve a senior technologist (me) telling a whole bunch of junior technologists what to do. It turns out I was right.

I started my first real Agile software development project in 1999. I'd been doing more traditional software development before then all the way back to 1980. I won't bore you with the details of those earlier projects, but my feeling was that there had to be a better way of developing software that didn't involve a senior technologist (me) telling a whole bunch of junior technologists what to do. It turns out I was right.

But almost from the start I got pushback from other people in the development organizations I worked in that Agile development was horribly wasteful. They pointed to Test Driven Development ("all those tests more than double your effort"), pair programming ("two developers doing the work of one?"), and refactoring ("you're rewriting the software every time at enormous cost"). Of course all of these objections were born not just out of a misunderstanding of Agile development, but a fundamental misunderstanding of how their own software development processes actually worked.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Post-Agile in the Game Development World?

Dietrich Kappe, Monday, February 15, 2010 @ 4:52 am

photo credit: Rich B-S

Gwarred Mountain over at Climax Studios has posted a very thoughtful blog post about software development methods and the appropriateness of Agile Software Development. I was ready not to like this article, what with the title and things like this:

If I have to sit through another meeting with some little "agile" toe-rag defending their train wreck of a project then I may end up forcibly ramming a kanban where the scrum does not shine.

But then I thought about all of those fresh-faced management consultants we've run into recently -- who have read a book about agile -- trying to teach us how to do it. Well, yes. I've had some uncharitable thoughts myself. Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

User Driven Product Development

Dietrich Kappe, Monday, January 25, 2010 @ 8:02 pm

photo credit: Hugo90

This morning I sat through two pitches by two startups looking for funding. I won't get into the details, but they both had clever ideas at their root. But while one company was attractive and poised for success, the other was mediocre and not getting much traction. Why was that? They both had clever ideas, no?

Over the years I've looked at a lot of business plans for Venture Funds. The first lesson that I learned was that cool ideas didn't equal successful companies. While I would get all hot and bothered by a particularly elegant software solution, the VC's I was consulting to preferred the plans that understood the market and the customers in it (and had a kick ass management team, natch).
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

What’s the value of Agile out of the box?

Michael Walkden, Tuesday, January 12, 2010 @ 10:24 pm

I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to explain to customers. While I was reading Leading Lean Software Development I discovered something that helps. The Poppendieck’s point out that the engineering practices of Agile (TDD, collective code ownership, etc…) are solid and not likely to change. But, the project management practices implement a system on top of another system - a hack.

Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.

Photo Credit:
kevindooley
under a Creative Commons Attribution License

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Review: Leading Lean Software Development

Michael Walkden, Sunday, January 10, 2010 @ 8:10 am

In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.”  If you are completely new to agile and lean you the book might move a little fast for you.  If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.

If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency.  These companies make money to survive rather than simply surviving to make money.

The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.”  A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.

Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.

Conclusion

I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

The Dog Ate My Software: Agile is not Undisciplined

Dietrich Kappe, Monday, January 4, 2010 @ 5:00 am

photo credit: LKaestner

Back in college I used to work at the main campus computer center. That was back in the days of time sharing Unix and mainframe computers, so it was a great way to get some extra CPU time for my various projects. Besides locking up at closing time (I loved to work the 10pm-3am shift), I had to change toner cartridges, support the brick macs, windows 3.1 machines, and the various Unix and Mainframe terminal users.

Over time, you learned to identify various user types. The vast majority of users had simple "hey, how do I do this" or "this ain't working" types of issues. Of the rest there were two main problem user types: the "helpless bunny" and the "walking crisis."

The Bunny displayed profound helplessness in order to get you to do their work for them. The first time I had a Bunny, I was caught unawares and spent the better part of my shift formatting their document in Wordperfect. With subsequent Bunnies, I used tough love and gave them manuals and man pages to read.

The Walking Crisis was typified by the grad student who waited until the last moment to add end notes to their masters dissertation, and dammit, if they were going to suffer, you were going to suffer. Their technique was to try to convince you that their problem was your problem, i.e. the fact that they couldn't do two months of work in five hours was a shortcoming of the software, and thus a support issue.

The more enthusiastic you were about helping users, the more susceptible you were of being dragged down by the Bunny and the Crisis.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

What does Google Chrome do for Mac based Flex Developers?

Sasha Dzeletovic, Monday, December 28, 2009 @ 11:30 am

Do you know every detail in the Flex framework by heart? Do you also know all the other libraries that you use by heart? Well I don't and I often have to reference some online resource while developing.

For instance, I always have Action Script Language Reference, Wikipedia, some library API site(s), Gmail and a dozen other ones open + the debug version of the app at hand.

So what used to happen when you but a breakpoint in Flex Builder with all these tabs? They would be unavailable and any process happening inside of them could not be relied on. Since not all code runs well on first attempt, if the app crashed while testing ( think 3D, data intensive apps, etc.) the browser and all the tabs went down with it.

My solution so far was to use Firefox as a development browser and Safari ( since I'm Mac based ) as a browser for references and everything else. For crashing resolution, Firefox has a nice "Restore" option but it's not fun waiting for 15 tabs to reload.

So Google Chrome recently came out for Mac. It didn't impress me on Vista so I didn't care much. I guess I was in between of curious and bored so I decided to give it a spin.

What a pleasant surprise to see every tab running in a different process. My workflow feels so much better now that I'm not afraid that a bad line of code is going to take down my whole browser.

I've heard that IE8 also runs tabs as different processes but I'm not crazy about returning to development on Windows. I did try out Chrome on Windows 7 as a result of the Mac test and all the issues I've seen the first time around have been addressed. Kudos to Chrome development team.

Let's not forget to mention all the features that are missing on Google Chrome for Mac, primarily the lack of Bookmark Management, but Google Bookmarks or any online bookmarking service will do for now.

I can not wait to see more development being done on Google Chrome for Mac and it getting out of beta. I will not uninstall Firefox anytime soon but as a Flex developer I give Google Chrome for Mac high scores for beta.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Requirements Set in Stone and Software Made of Concrete

Bernhard Kappe, Monday, December 21, 2009 @ 12:06 pm

Twas the night before Christmas, and 500 pages of detailed requirements had been produced. No line of code had been written, not even by a mouse.

It sounds great in theory: You produce requirements up front, getting them so detailed that they cannot be misunderstood, you vet them with a full committee of stakeholders who will be impacted (except your customers.) Then you give it to the developes. The result: you can get a really precise cost and timeline, you'll save on expensive development time, and your CFO will sleep soundly at night.

It's a nice fantasy, but it's wrong. It's a fundamental misinterpretation of how software development works. In fact, it's a guaranteed way of increasing your costs and producing bad software.

Here's why:
If you're developing software, you're coming up with a new solution to a problem, or solving a new problem all together. Otherwise, why are you building software, rather than buying it?

Traditional requirements definition processes are a spectacularly bad way of understanding stakeholder needs, and coming up with, conveying and vetting a solution for these types of problems. You will miss certain requirements, you will over specify others, and some of them will never get used. Your stakeholders will only be able to provide feedback of limited value until the working software is actually in their hands. At that point, you will finally start getting valuable feedback that you can push through as change orders.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Your SDLC or Your Product – You Decide

Michael Walkden, Wednesday, December 9, 2009 @ 10:33 pm

…or the telephone game

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Fake Agile: All of the Symptoms, but not the Disease

Dietrich Kappe, Monday, December 7, 2009 @ 12:56 pm

photo credit: Ramón Peco

For any software development professional who has contracted out from time to time, this story must seem familiar. You interview and are told that they practice agile development. Once you show up at the job site, they tell you they practice their own "brand" of agile, which turns into "sort of agile" or "we've take the best parts of a couple of different methods" or "it isn't exactly" -- wild and crazy hand gestures -- "XP."

It's a classic case of people following the form or ritual of a process without understanding the why of it. Take the morning scrum, for instance. The ritual around these usually calls for them to be done standing up. We've of course all heard of the standups that run an hour or two. Someone on that team doesn't understand the function and is following the ritual.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Big Faceless System, Version 5

Dietrich Kappe, Monday, November 30, 2009 @ 5:45 am

photo credit: Daquella manera

When you're in software development you sometimes get called in via the Bat Signal -- a project is going sideways and management feels they need more bodies or different bodies to get the thing back on track. For a while now we have turned down "gasoline" work (see The Mythical Man Month on throwing gasoline on the fire by adding more developers) but still do a fair amount of toxic software project remediation.

In one particular case the system in question was several months late and substantially over budget. After a few days of reading documents, interviewing developers and meeting with stakeholders, one thing stood out. This system -- we'll call it "Cool Beans" -- was in fact "Cool Beans 5," i.e. the fifth version of this system. I asked the product manager the obvious question: "What was wrong with versions one through four?"

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Advice to Developers: Try Understanding the Business

Dietrich Kappe, Wednesday, November 25, 2009 @ 1:47 pm

The flip side of my advice to business people to start treating your developers like adults is that developers have to start behaving like adults. What does that mean? Well, my point is that in order for business people to include developers in business discussions, developers have to be ready and willing to understand and participate in those discussions. And that means a little bit of homework.

For developers to understand why this is important, just think about the client/stakeholder you've worked with who has been the most willfully ignorant of the software development process -- the sort of client that demands things that are hard or impossible to do with software and then throws a tantrum when someone tries to explain this to them. Who wants to work with that person? No one. Think of how ineffective that appdev team is with this person gumming up the works and whipsawing the team with unreasonable demands.

Now put yourself in the shoes of a business person who is dealing with developers who are ignorant of basic business concepts. Why would you entrust such folks with any degree of authority for developing a new software product for your company? You wouldn't.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Innovation and Treating Developers Like Adults

Dietrich Kappe, Monday, November 23, 2009 @ 5:28 pm

Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
-- Tom Smykowski

photo credit: sdminor81

I get a lot of grief when I talk about agile practices and how it ends some inefficiencies, i.e. less personal activity during work hours by developers. One commenter on my last article on the benefits of pair programming put it thusly:

It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

He's right, but not for the reason he states. Pair programming is still better than solo programming in almost all cases. Treating developers like children, however, is a sin that is pervasive in many businesses. In my advocacy for pair programming, I was subconsciously pitching my message to product and development managers in large organizations.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

What is the ideal Senior Developer skillset?

John McCaffrey, Wednesday, November 11, 2009 @ 4:21 pm

We're currently in the process of interviewing candidates for 1-2 Senior, and 2-3 junior level Rails Developers, and I'm wondering about the skills that are most critical, and how best to identify the best candidates.

My normal interview process flows like this:

1. Quick Phone screen evaluating basic development skills, background, availability, personality
2. Basic coding problem (less than 1hr to complete)
3. Phone call to review coding problem, 'how would you handle X?' questions, etc
4. On site interview targeting: Communication, Communication, Communication, (and tech)
5. Final decision

Independent of the language they will be working with, I've found decent success with having candidates answer some standard dev questions, solve a basic coding problem, and demonstrate their ability to whiteboard a design.

The problem is that it doesn't scale. When we've opened up positions in the past, either Senior or Junior, there have been so many applications that its hard to contact them all. This leads to a reshuffling of the tasks and matching criteria, in an attempt to identify the 'best' matches, and 'filter out' the others.  So instead of calling each candidate first, we might simply reply to them with the details of the coding assignment. I've seen 40 people send the "I'm an extremely hard worker, very interested in your position and would do anything to join your wonderful company" cover letter and resume, and then get whittled down to only 10 candidates that actually submit the assignment.  (Note to applicants: 'showing up' is an important first step!)

I came across an interesting post titled '11 tips on hiring a rails developer' which mentioned some 'filtering' criteria to identify the best candidates

You can read the full description of each one, but there are a few of these that I wanted to highlight:

1. Don't use Monster.com or recruitment agencies.
2. Poach Talent from other companies!
   
3. Don't hire someone that doesn't know Rails at all.
4. Look for open source contributions.
5. A personal Rails blog is required.
6. A university degree is not important.
7. Be wary of holes in proficiency.
8. Avoid brand-name superstars.
9. Hire perpetually.
10. Have a company Rails blog
11. Special compensation.

So each of these tips is meant as a heuristic or proxy of the true underlying ability. Any time you are making generalizations you are going to miss out on a few exceptions, but hopefully you end up with what you are looking for.

Starting with the most controversial first, (#5) while I like the idea of giving a strong preference to someone that has a rails blog, and loves  Ruby, Rails, and Web Development enough to be opinionated and spend their own time ranting about it, I'm not sure I could make it a filtering criteria. Doesn't that seem a bit strong?

I feel the same about (#4) Open Source contribution. I think its great if they have it, but I'm not sure I would reject any candidates that haven't contributed to open source.

While I've met many systems administrators that (#6) don't have a degree, and are very good at their craft, I haven't really encountered many solid developers that don't have a degree. That's not to say they aren't out there, I'm just saying I've never encountered them, and I'm reluctant to use it as a filter. Do you think that there are many strong Rails developers out there without degrees? (I don't care if they have a CS degree, but I think I prefer that they have some kind of degree)

As it relates to (#1) and (#11), I know for sure that the economics of finding a candidate through your own network and contacts can be less expensive than the recruiter fees (assuming you find a decent candidate and don't waste a lot of your own time doing it), and if you are able to find someone directly, it frees up cash for such amenities as 'New Macbook Pro', 'RailsConf', and 'Fridge full of XXX'.

If I was in charge of everything

I really like what Andy Singleton describes regarding how his team at Assembla is organized and tackles Agile Development, and on the right project, I'd really like take his advice and try this one:

"Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do."

Anyways,  I'd be very interested in your thoughts regarding what makes for a Solid Rails developer, where you find them, how you keep them, and what you've learned.

(Oh, and if you know any passionate Rails Developers in the Chicago area, send them over!)

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development