Home
The Agile Developer
 Kirk is an Analyst at Burton Group. For 15 years, he's worked in the trenches on real software projects. Kirk
believes software development is an amazing profession. He take a keen
interest in design, architecture, application development platforms,
agile development, and the IT industry in general, especially as it
relates to software development.
Subscribe to this RSS Feed - 
|
|
Written by Kirk Knoernschild
|
|
Saturday, 08 March 2008 |
 Over the past two years, I've written numerous articles as part of The Agile Developer column. Most of these articles have been focused, specialized pieces explaining an agile practice or team dynamic that helps increase agility. Throughout, I've always shared a small piece of my agile development experience, occasionally cross-referencing the material. Until now, however, I haven't shared insight to how everything fits together.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Saturday, 09 February 2008 |
 Design and
code reviews promise to improve software quality, ensure compliance with
standards, and serve as a valuable teaching tool for developers. As with most
practices, there are subtle nuances surrounding how they're performed that can
dramatically affect their value. In some organizations, reviews are a valuable
aspect of the software lifecycle. In others, they are a necessary evil tainted
with political bureaucracy and big egos. Sub-optimal reviews conducted late in
the lifecycle are often misguided due to few objective guidelines that help
guide the review process. When used throughout the development lifecycle, code
and design quality metrics are valuable inputs to the review process.
|
|
|
Written by Kirk Knoernschild
|
|
Saturday, 05 January 2008 |
 Last
year, I resolved that in 2007 I'd focus on the essential characteristics of
technology that help maximize the effectiveness of agile practices. Since about
90 percent of folks don't keep their resolutions throughout the year, I've
decided this year not to make any such promises. Instead, I'll let you make
your own resolutions this year, and will offer up a few tips that you might
want to consider seriously if you're interested in increasing your personal or
team's agility.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Saturday, 10 November 2007 |
 Agile has grown
and evolved from a very simple developer centric process defined by Extreme
Programming to a complex product brand that enterprises are using to bring more
resiliency to governance programs, enterprise architecture initiatives, and
application portfolio management efforts. But at its roots, there remains a key
fundamental aspect that defines the essence of agility on the software
development project. Continuous Integration is a strategy where software is
integrated and built continuously, or at least as frequently as is feasibly
possible. Many teams have adopted a continuous integration strategy, yet do not
fully realize all the benefits that continuous integration might bring to the
development effort. This article discusses the subtle though significant ways
that continuous integration can be leveraged -from helping to align IT with the
business to enforcing architectural constraints - and shows that this
fundamental aspect of agility is the defining and necessary element of a truly
agile development experience.
Tags:
stuff,
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Wednesday, 12 September 2007 |
|
Enterprise software development isn't fun
anymore. As young geeks, we pursued a career in software development because we
enjoyed technology, especially the part where we used a programming language to
create software programs. You remember, right? Each day at work was filled with
something new, exciting, and often-times profound. But for senior technologists
with their sustainable passion for technology, software development today is
less about writing code and more about performing other mundane activities that
we not only dislike, but know are counter-productive to our end goal. But agile
development, with its proven emphasis on individuals and working software, has
the ability to make software development fun again. If we're able to bring
agile to the enterprise, we just might make software development the way it
ought to be - enjoyable, productive, and valuable.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Sunday, 08 April 2007 |
We have been taught that the best way to solve the tough challenges inherent in software development efforts is to treat software development as an engineering discipline. Stabilize requirements early, and then follow by analysis and design, implementation, verification, and deployment. Throughout each of these lifecycle phases, teams produce traceable artifacts where changes to one artifact is ideally traced through to other artifacts, eventually leading to the source code modules that must change. But traceability is fundamentally flawed due to the manual effort required to synchronize artifacts. As deadlines loom and pressure mounts, we do not possess the discipline to ensure consistency across all artifacts. Slowly, requirements specifications and design models diverge and no longer offer an accurate view of current system behavior or structure. Avoiding the issues inherent to traceability demands we shift from traceable artifacts to executable artifacts.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Sunday, 11 March 2007 |
|
For many teams, agile adoption represents an attempt to improve their software process. As an industry, we've been through these process improvement efforts before. Yet we continue to fail. Software development efforts fail because our attempts to improve process are fundamentally flawed. Many adaptations of the most popular iterative and incremental processes are little more than reinventions of faulty practices. They result in slightly varied manifestations of the same problems that have plagued the software industry for years. We will continue to experience this problem until we divert our attention away from software process improvement as an attempt to improve process toward software process improvement as an attempt to speed software delivery. To start, we must focus on the only software artifact required to deliver an application - the code - and begin treating source code as a corporate asset.
Tags:
Click to add your tags...,
|
|
| | << Start < Prev 1 2 Next > End >>
| | Results 1 - 11 of 15 |
|
