Fellow Macadamian, founder, and Chief Architect at Macadamian has written a great Critical Path article on why design thinking is failing to penetrate software companies.
I had an AH-HA moment when Francis mentioned that "Agile is not a process, it's a mitigation strategy". Truer words have never been spoken.
If you are interested in more about what Alan Cooper thinks about design and Agile, catch his keynote address at Agile 2008, it was very controversial.
This is his complete slide deck and his speaking notes, sorry, no audio. If you want to listen to the audio, one of the attenders of the conference taped it.
Thursday, January 29, 2009
Monday, January 26, 2009
A Time appreciation by any other name...
The "last responsible moment" is a term that is talked about a lot in agile and "flexible product development".
The most recent edition of the edition of the Agile Journal has a neat little comic talking about how you calculate the last responsible moment.
As I was reading through this comic I came to a realization, it is what the military would call a time appreciation. You start with when you need the task to be done by and work backwards. It is a pretty simple exercise in logical analysis and problem solving.
In other words, no smoke and mirrors.
The most recent edition of the edition of the Agile Journal has a neat little comic talking about how you calculate the last responsible moment.
As I was reading through this comic I came to a realization, it is what the military would call a time appreciation. You start with when you need the task to be done by and work backwards. It is a pretty simple exercise in logical analysis and problem solving.
In other words, no smoke and mirrors.
Thursday, January 15, 2009
Who wags who?
It's an old joke to ask if the dog wags the tail, or the tail wags the dog. The saying fits in many contexts outside of media, including the age old battle between testing and engineering, or the usability of the application, and the technical design of the application. Do the user experience (UX) folks design without regards to the technical feasibility of their work, or does the engineering team dictate design by imposing technical constraints?
Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!
At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.
Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.
The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.
Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.
To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.
This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.
Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.
Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.
The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.
Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.
To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.
This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.
Monday, January 12, 2009
Just Fake It
No matter what some people might say, faking it is perfectly acceptable. Seriously, faking it allows you to get finished your task sooner. Some people think that faking is cheating, but it's not.
Ok, enough with the double entendres, what am I really talking about? Why using mock objects or stubs of course.
Stubs are more common in the types of projects that we tend to do, but we do use mocks as well. I really like these design patterns and try to use them often to decouple different teams from each other. This being said, the concept of stubbing and mocking is starting to become a bit of a lost art.
Once the interface and supporting data structures are designed, one team can start to work on developing the user interface using stubs and mocks whilst the back end team works on implementing the actual functionality.
This has several benefits:
By the smart application of mocks and stubs, the manager can reduce the overall critical path of the project and the dependencies on the back end team. All the teams need to collaborate together to define the interfaces and use cases, but once that is done the teams can work independently, and most importantly, in parallel. Without the use of stubs and mocks, the user interface team for example, would be unable to accomplish much work until the back end was implemented.
Creation and Maintenance of Unit Tests
Many teams and projects now work in the Test Driven Development methodology, or at the very least rely on unit tests to demonstrate correctness of the code and help guard against regressions. The use of mocks and stubs can help encourage the creation and maintenance of unit tests by allowing the developers to first stub the back end and then write the unit tests to exercise the interfaces. Additionally, mocks provide the ability for the unit test writer to write the unit tests that exercise code that relies on complex objects. Additionally, since mock objects implement the interface and simulate more complex real objects they allow programmers to implement and unit-test features in one part of the application without actually having to call the more complex underlying objects. A broad, well maintained unit test suite will give you the manager a lot of confidence with regards to the overall quality of the application. In addition, a good test suite can give the manager a lot of confidence to approve the re-factoring exercise without fear of introducing regressions.
Facilitates top-down coding
Stubbing and mock objects are an essential part of the top-down coding methodology, or as some people like to call it "breadth-first coding". Read the link for a much more detailed explanation then what I have room here for.
Validation of APIs and Data structures
Often "paper" doesn't match reality, and the best designs on paper fall apart in real life applications. The use of mocks and stubs that meet the interface requirements and behaviors of the design allow the users of the interfaces and complex objects to actually use them in a real life scenario while the real implementations are still progressing. This can safe costly redesign and re-factoring exercises, both in terms of budget and schedule.
Move the big rocks first
Clever use of stubs and mocks allows the team to focus on solving the big technical hurdles without getting bogged down in the small little details of the project, the so called while stubbing "boilerplate" functionality. For example, your web application needs to implement complex domain specific functionality that requires a lot of collaboration between the development teams and the stakeholders, of course you need user management and login, but those problems have been solved a thousand times before, and the amount of work required to implement them is well known, leave the actual implementation to the end. Removing the technical hurdles upfront in the project allows the manager to more accurately estimate the end date of the project as the most riskiest items in terms of budget and schedule have been solved.
Separation of teams
With today's global teams distributed across the globe all efforts have to be made to decouple the teams and reduce time to market while at the same time keeping the project as a whole cohesive and highly productive. When the developers from your user interface team come to you and say they are blocked because they are waiting for the back end guys to finish their service layer, or that no one but the team here in the head office can work on that feature because it depends on another feature from another team, remind them of the concept of stubbing the APIs and mocking the complex pieces in the interim, this may well indeed allow another team in another location work on that feature with little to no impact in quality or time to market. Of course the teams still need to communicate constantly with each other. The ability to easily separate areas of the application will help the manager build out the team in multiple locations, potentially allowing the team to grow faster then could be hired locally.
Ok, enough with the double entendres, what am I really talking about? Why using mock objects or stubs of course.
Stubs are more common in the types of projects that we tend to do, but we do use mocks as well. I really like these design patterns and try to use them often to decouple different teams from each other. This being said, the concept of stubbing and mocking is starting to become a bit of a lost art.
Once the interface and supporting data structures are designed, one team can start to work on developing the user interface using stubs and mocks whilst the back end team works on implementing the actual functionality.
This has several benefits:
- It removes the back end team from the critical path
- Facilitates the creation and maintenance of unit tests
- Facilitates the top-down coding methodology
- Provides an actual user of the APIs and data structures to validate their design
- Allows the team to focus on the big technical risks
- Helps facilitate the separation of teams
By the smart application of mocks and stubs, the manager can reduce the overall critical path of the project and the dependencies on the back end team. All the teams need to collaborate together to define the interfaces and use cases, but once that is done the teams can work independently, and most importantly, in parallel. Without the use of stubs and mocks, the user interface team for example, would be unable to accomplish much work until the back end was implemented.
Creation and Maintenance of Unit Tests
Many teams and projects now work in the Test Driven Development methodology, or at the very least rely on unit tests to demonstrate correctness of the code and help guard against regressions. The use of mocks and stubs can help encourage the creation and maintenance of unit tests by allowing the developers to first stub the back end and then write the unit tests to exercise the interfaces. Additionally, mocks provide the ability for the unit test writer to write the unit tests that exercise code that relies on complex objects. Additionally, since mock objects implement the interface and simulate more complex real objects they allow programmers to implement and unit-test features in one part of the application without actually having to call the more complex underlying objects. A broad, well maintained unit test suite will give you the manager a lot of confidence with regards to the overall quality of the application. In addition, a good test suite can give the manager a lot of confidence to approve the re-factoring exercise without fear of introducing regressions.
Facilitates top-down coding
Stubbing and mock objects are an essential part of the top-down coding methodology, or as some people like to call it "breadth-first coding". Read the link for a much more detailed explanation then what I have room here for.
Validation of APIs and Data structures
Often "paper" doesn't match reality, and the best designs on paper fall apart in real life applications. The use of mocks and stubs that meet the interface requirements and behaviors of the design allow the users of the interfaces and complex objects to actually use them in a real life scenario while the real implementations are still progressing. This can safe costly redesign and re-factoring exercises, both in terms of budget and schedule.
Move the big rocks first
Clever use of stubs and mocks allows the team to focus on solving the big technical hurdles without getting bogged down in the small little details of the project, the so called while stubbing "boilerplate" functionality. For example, your web application needs to implement complex domain specific functionality that requires a lot of collaboration between the development teams and the stakeholders, of course you need user management and login, but those problems have been solved a thousand times before, and the amount of work required to implement them is well known, leave the actual implementation to the end. Removing the technical hurdles upfront in the project allows the manager to more accurately estimate the end date of the project as the most riskiest items in terms of budget and schedule have been solved.
Separation of teams
With today's global teams distributed across the globe all efforts have to be made to decouple the teams and reduce time to market while at the same time keeping the project as a whole cohesive and highly productive. When the developers from your user interface team come to you and say they are blocked because they are waiting for the back end guys to finish their service layer, or that no one but the team here in the head office can work on that feature because it depends on another feature from another team, remind them of the concept of stubbing the APIs and mocking the complex pieces in the interim, this may well indeed allow another team in another location work on that feature with little to no impact in quality or time to market. Of course the teams still need to communicate constantly with each other. The ability to easily separate areas of the application will help the manager build out the team in multiple locations, potentially allowing the team to grow faster then could be hired locally.
Friday, January 9, 2009
What's good constructive criticism?
Jason Cohen over at Smart Bear has a great article on what differentiates constructive criticism from bad business advice.
As a manager at Macadamian I am often asked my opinion on many subjects, from straight project management, to leadership and people management, to personal matters of some of the people that work with me. Jason's blog post makes some great points on how to recognize great constructive criticism, so it only makes sense that take some of those points and apply them when giving advice or constructive criticism.
I agree that often people seeking advice know what they need to do, they just don't necessarily know that they know, and asking pointed questions can often guide the person to the answer they are looking for.
Oh, and I will try to never ever say "because that's they way it was always done".
As a manager at Macadamian I am often asked my opinion on many subjects, from straight project management, to leadership and people management, to personal matters of some of the people that work with me. Jason's blog post makes some great points on how to recognize great constructive criticism, so it only makes sense that take some of those points and apply them when giving advice or constructive criticism.
I agree that often people seeking advice know what they need to do, they just don't necessarily know that they know, and asking pointed questions can often guide the person to the answer they are looking for.
Oh, and I will try to never ever say "because that's they way it was always done".
Thursday, January 8, 2009
No, actually that's my latent superhero powers manifesting
Ok so I am not really a superhuman, too bad eh?!
This looks like a really cool toy, not quite as cool as a parental version that allows a parent to put the headset on a direct the child to clean their room!
This looks like a really cool toy, not quite as cool as a parental version that allows a parent to put the headset on a direct the child to clean their room!
Tuesday, January 6, 2009
How does a web developer spend their time?
Not many people understand how the average developer spends their time while creating web content. If you haven't done large scale web development, you just don't get it. Hopefully the graph below will help explain how their time breaks down, and maybe help move them up the totem pole.
Thursday, January 1, 2009
Subscribe to:
Posts (Atom)
