It's a small world after all, and no where is that more evident than in the world of software, where differences in language and desktop settings can cause applications to crash with no warning.
Get the software engineering slant on items from the recent news.
Turn to The Last Word, where software professionals who care about quality give you their opinions on hot topics. This month, Karl Wiegers shares some common misperceptions about requirements.
We're pleased to bring you technical editors who are well respected in their fields. Get their take on everything that relates to the industry, technically speaking. In this issue, discover why reflex might be the key to better software development.
One school of thought says each should do what he's best at and no more. But one company has graduated to a new way of life. Instead of isolating testers and business analysts, the two teams are melded into one—resulting in a more robust product created in less time at a reduced cost. Could this hybrid approach work for you?
System documentation is a pain to do and it's even harder to keep up to date. What if, by refining the unit tests you already are doing, you could create documentation automatically, and have it be automatically updated? Find out how one team is making it work for them.
Developers are a unique bunch. They tend to have innate characteristics that cause them to approach problems in ways that leave their managers scratching their heads. Discover what natural behaviors are likely to cause conflicts and what you can do to work with those instinctual traits, instead of against them.
We crank out bug reports and expect them to return like a boomerang so we can check to see if the bugs were fixed. In this week's column, Danny Faught shares some ideas drawn from recent experiences that could make you a better customer advocate subsequent to filing a bug report.
There's no shortage of advice on how you should model, design, test, build, and deploy your software project. Every author, trainer, and pundit will swear up and down that "they know the secret." They know how to build great software--they've done it before and all you have to do is follow their lead. Buy their software, read their books, buy their tools, attend their seminars, and do it just like they do it and you'll be a success, right? But somehow it doesn't seem to be that easy. In this week's column, the first in a series of articles that will explore the different avenues of software development, Andy Hunt and Dave Thomas, the Pragmatic Programmers, begin the journey by revealing that learning software development isn't as easy as the pros make it out to seem. Find out why these books and seminars work for them, but not always for the rest of us.
Getting process improvement "just right" is difficult. Go too far in the definition of processes, and it really does get too hot, with the heat coming from the people trying to use the processes. On the other hand process definitions that are too short to contain anything of value will leave users in the cold, and then there will be no improvement in the organization. Ed Weller states that a useful process improvement activity develops a set of process artifacts that meets the needs of the user. This helps the organization capture "tribal lore" and cast it into a set of process definitions that eliminates waste and improves time-to-market.
Agile Connection is one of the growing communities of the TechWell network.
|Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery. Join the conversation now!|