Balsamiq Mockups in Action

About a couple of weeks ago i had searched for tool to make a future site prototype. After spending some time googling i've found a nice tool called Balsamiq Mockups, aimed to help developers with creating funny looking mockups of software application, website or whatever you are planning to implement or realize. So i started playing with it. Installation was pretty simple, all you need is to download and install AIR packaged application, and you are ready to go.
Workspace of application is like a whiteboard, where you can place predefined components like buttons, menus, text, links, and many other things.

All components are styled in one fashion, so they harmonically fit one to each other and look very pretty. When you are done, completed mockup is like a hand-drawn sketch.
Here is result of my work with this amazing tool:

And here is a realized project: http://variamind.com. Try to find 10 differences ;)
If you had searched for tool like this to fulfill your needs, take a look at Balsamiq Mockups. You will be impressed with its features. Feel free to discover how creation of interfaces turns into game, full of fun;) Thanks for great work, guys, your tool is really rocks!
Download is available here.

Find and retain passionate problem solvers

Putting together a team of outstanding developers is one of the most important things you can do to ensure the success of a software project. While the concept of keeping that team together does not seem to get as much lip service, it is equally important. Therefore, you need carefully select your development team and diligently protect it once assembled.

Most people probably agree that finding top-notch developers requires thorough technical interviewing. But what does thorough mean exactly? It doesn’t mean requiring candidates to answer difficult questions about obscure technical details. Screening for specific technical knowledge is definitely part of the process but turning an interview into a certification test will not guarantee success. You are searching for developers with problem solving skills and passion. The tools you use are sure to change; you need people who are good at attacking problems regardless of the technologies involved. Proving someone has the ability to recite every method in an API tells you very little about their aptitude or passion for solving problems.

However, asking someone to explain their approach to diagnosing a performance problem gives you great insight into their methods for problem solving. If you want to learn about developer’s ability to apply lessons learned, ask what they would change given the chance to start their most recent project anew. Good developers are passionate about their work. Asking them about past experience will bring out that passion and tell you what correct answers to technical trivia questions cannot.

If you have been diligent in staffing a strong team, you want to do whatever is within your power to keep the team together. Retention factors such as compensation may be out of your hands but make sure you’re taking care of the little things that help to foster a healthy work environment. Good developers are often strongly motivated by recognition. Use this fact to your advantage and acknowledge stellar performances. Finding great developers is difficult. Letting people know they are valued is not. Don’t miss simple chances to build morale and boost productivity.

Be careful with negative re-enforcement. Too much of it may stifle a developer’s creativity and reduce productivity. Worse yet, it’s likely to create dissension among the team. Good developers are smart; they know they’re not wrong all of the time. If you’re picking apart the minutia of their work, you’ll lose their respect. Keep criticism constructive and don’t require that every solution look like it came from you.

The importance of staffing your development team correctly can’t be overstated. These are the people who do the heavy lifting. When it comes to estimates, they’re all treated as equal producers. Make sure it’s tough to crack the starting lineup and once you’ve got a winning team go the extra mile to keep it together.

by Chad LaVigne

This work is licensed under a Creative Commons Attribution 3

Don't Be Clever

General intelligence, resourcefulness, thoughtfulness, a breadth and depth of knowledge, and an affinity for precision are laudable qualities in anyone, particularly prized in architects.

Cleverness, however, carries a certain additional connotation. It implies an ability to quickly conceive of a solution that may get you out of a jam, but that ultimately rests on a gimmick, a shell game, or a switcharoo. We remember clever debaters from high school--always able to play semantics or work the logical fallacies to win the point.

Clever software is expensive, hard to maintain, and brittle. Don't be clever. Be as dumb as you possibly can and still create the appropriate design. The appropriate design will never be clever. If cleverness appears absolutely required, the problem is incorrectly framed; reset the problem. Reframe it until you can be dumb again. Work in rough chalk sketches; stay general. Let go of the flavor of the day. It takes a smart architect to be dumb.

It is our cleverness that allows us to trick software into working. Don't be the attorney who gets your software off on a technicality. We are not Rube Goldberg. We are not MacGyver, ever-ready to pull some complicated design out of our hats having been allowed only a paper clip, a firecracker, and a piece of chewing gum. Empty your head and approach the problem without your extensive knowledge of closures and generics and how to manipulate object graduation in the heap. Sometimes of course, such stuff is exactly what we need. But less often than we might think.

More developers can implement and maintain dumb solutions. In dumb solutions, each component can only do one thing. They will take less time to create, and less time to change later. They inherit optimizations from the building blocks you're using. They emerge from the page as a living process, and you can feel their elegance and simplicity. Clever designs will stay stubbornly rooted; their details are too embroiled in the overall picture. They crumble if you touch them.

By Eben Hewitt


This work is licensed under a Creative Commons Attribution 3

Learn a new language

To be successful as an architect, you must be able to make yourself understood by people who don’t speak your native tongue. No. I’m not suggesting you learn Esperanto or even Klingon, but you should at least speak basic Business, and Testing. And, if you aren’t fluent in Programmer, you should make that a top priority.

If you don’t see the value in learning other languages, consider the following scenario. The business people want a change made to an existing system, so they call a meeting with the architect and programmers to discuss it. Unfortunately, none of the technical team speaks Business and none of the business people speak Programmer. The meeting will likely go something like this:

A business person talks for a minute about the need for a relatively simple enhancement to an existing product, and explains how making the change will enable the sales team to increase both market and mind share.

While the business person is still speaking, the architect starts sketching some kind of occult symbols on a notepad and enters into quiet argument with the one of the programmers in their strange multi-syllabic tongue.

Eventually the business person finishes and looks expectantly at the architect.
After the whispered argument completes, the architect walks to the whiteboard and begins drawing several complex diagrams that are supposed to represent multiple views of the existing system while explaining (in complex technical terms) why the requested enhancement is virtually impossible without major changes and may actually require a complete redesign/rewrite of the entire system.

The business people (who understood little of the diagram and less of the explanation) are openly stunned and find it hard to believe that something so simple would require such massive changes. They begin to wonder if the architect is serious or just making things up to avoid making the change.

Meanwhile, the architect and programmers are just as surprised that the business people don’t see how the “minor” change will require major modifications to the core system functionality.

And therein lies the problem. Neither group understands how the other thinks, or what half of the words they use means. This leads to mistrust and miscommunication. It’s a basic psychological principle that people are more comfortable with those who are similar to them as opposed to those who are different from them.

Imagine how the above scenario might change if the architect were able to explain the issues to the business folk in terms they understand and relay the business issues to the programmers in terms they understand. Instead of surprise and mistrust, the result would be agreement and approval.

I’m not saying that learning multiple languages will cure all your problems, but it will help prevent the miscommunications and misunderstandings that lead to problems.

For those of you who decide this makes sense, I wish you success on your journey. Or, as the Klingons say, Qapla!

by Burk Hufnagel

This work is licensed under a Creative Commons Attribution 3

Pattern Pathology

Design patterns are one of the most valuable tools available to the software architect. Using patterns allows us to create common solutions that are easier to communicate and understand. They are concepts that are directly associated with good design. This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project. If you find yourself trying to shoehorn your favorite patterns into a problem space where they don’t apply, you may be a victim of pattern pathology.

Many projects suffer from this condition. These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying “Now, which one will I use first!?”. This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”. Design patterns are excellent tools for mitigating necessary complexity but like all tools, they can be misused. Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail. Be careful that your appreciation for patterns doesn’t become an infatuation that has you introducing solutions that are more complicated than they need to be.

Stamping patterns all over a project unnecessarily is over-engineering. Design patterns are not magic and using them doesn’t automatically qualify a solution as good design. They are reusable solutions to recurring problems. They have been discovered and documented by others to help us recognize when we’re looking at a wheel that’s already been invented. It’s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately. Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision. Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.

by Chad LaVigne

This work is licensed under a Creative Commons Attribution 3

Make a strong business case

As a software architect, have you had a hard time getting your architecture project well funded? The benefits of software architecture are obvious for architects, but are mythical for many stakeholders. Mass psychology tells us that “seeing is believing” is the strongest belief for most people. At the early phase of the projects, however, there is little to demonstrate to convince stakeholders of the value of sound software architecture. It’s even more challenging in the non-software industries where most stakeholders have little software-engineering knowledge.

Mass psychology also shows that most people believe in “perception is reality.” Therefore, if you can control how people perceive the architectural approach you propose, it’s virtually guaranteed that you control how they will react to your proposal. How can you mange stakeholders’ perceptions? Make a strong business case for your architecture. People who have the budget authority to sponsor your ideas are almost always business-driven.

I have employed the following five steps to generate solid business cases to successfully sell my architectural approach many times in my career:

Establish the value proposition. The value proposition is your executive summary of why your organization’s business warrants a particular software architecture. The key for this is to compare your architectural approach with existing solutions or other alternatives. The focus should be put on its capability to increase the productivity and efficiency of the business, rather than how brilliant the technologies are.

Build metrics to quantify. The values you promise to deliver need to be quantified to a reasonable extent. The more you measure, the more you can bolster your case that sound architecture will lead to a substantial return. The earlier you establish metrics, the better you manage people’s perceptions that help you sell responsible architecture.

Link back to traditional business measures. It would be ideal if you can translate your technical analysis into dollar figures. After all, the only constant parameter in the traditional business measures is money. Find business analysts as your partners if you are not comfortable with financial work.

Know where to stop. Before you know where to stop, you need to prepare a roadmap that captures a vision with each milestone on it tied directly to business values. Let the stakeholders decide where to stop. If the business value for each momentum is significant, you’re most likely to get continued funding.

Find the right timing. Even if you follow the above four steps to generate a solid business case, you may still not be able to sell your ideas if you pick the bad timing. I remember one of my proposals did not get approved for a long time until another project turned out to be a total failure because of poor architectural design. Be smart on timing.

by Yi Zhou

This work is licensed under a Creative Commons Attribution 3

Choose Frameworks that play well with others

When choosing software frameworks as a basis of your system, you must consider not only the individual quality and features of each framework, but also how well the set of frameworks that make up your system will work together, and how easy it will be to adapt them to new software you may need to add as your system evolves. This means you must choose frameworks that do not overlap and that are humble and simple and specialized.

It will be best if each framework or 3rd party library addresses a separate logical domain or concern, and does not tread into the domain or concern of another framework you need to use.

Make sure you understand how the logical domains and concerns addressed by your candidate frameworks overlap. Draw a Venn diagram if you need to. Two data models that overlap substantially in domain, or two implementations that address very similar concerns but in slightly different ways, will cause unnecessary complexity: the slight differences in conceptualization or representation must be mapped or patched with kludgy glue code.

Chances are you'll end up not only with complex glue, but also with the lowest-common-denominator of the functionality or representative power of the two frameworks.

To minimize the chance that any given framework will overlap with another framework, choose frameworks that have a high utility to baggage ratio, in the context of your system requirements.
Utility is the functionality or data representation that your project needs from the framework. Baggage is the framework's sweeping, all-encompassing, I'm-in-charge view of the world. Does it insist on mixing data representation and control? Does its data model or set of packages and classes extend well beyond what your system needs? Do you have to become a fundamentalist in the framework's religion, and limit your choices of other frameworks to those of the correct denomination? Does its excess complexity limit the kinds of things you can mix with it? If a framework comes with lots of baggage, then that it had also better be providing 75% of the functionality value in your project.

Your system should be comprised of mutually exclusive frameworks, each of which may be a master of its domain, but which is also simple, humble, and flexible.

by Eric Hawthorne

This work is licensed under a Creative Commons Attribution 3