The design of good software is a constant battle with complexity. Great software designers mercilessly strip away all unnecessary complexity from a design. Necessary complexity they hide behind the simpler interfaces of more appropriate abstractions.
Understand the Problem
One of the keys to creating elegant designs is building a deep understanding of the problem being solved. Traditionally, the analysts and designers within a project team do this by building a complete, detailed understanding of the whole problem in a lengthy, analysis and design phase at the beginning of a project. These days, it is more likely that the whole team will sketch out an initial, overall, high-level understanding of the problem together as part of a short JEDI-style (Just Enough Design Initially) discovery or exploration exercise, and add the detail iteratively during development using a modern, agile development approach.
Techniques, Strategies and Patterns
Regardless of when we do it, analysis pulls apart a problem into its constituent components so we can better understand the structure and dynamics of the problem. From that understanding, design adapts and applies proven patterns, techniques and strategies to shape the architecture and behaviour of the software that provides the solution we require. Therefore, good designers, are always on the look-out for better analysis and design techniques, patterns and strategies.
Modelling in Colour
First used in 1997, Peter Coad's '
modeling in color' has consistently proven to be one of the most
effective techniques for initial, overall, analysis and design of
enterprise software. This is especially true when further informed by
the patterns and strategies from Nicola,
Mayfield, and Abney's, Streamlined
Object Modeling
Software development process is all about the way a team works together and interacts with all the other interested parties and teams in developing a piece of software.
Agile Software Development
The software industry has invented, proposed, debated, refined, celebrated, criticised, and derided numerous different processes, methods and approaches to team-based software development over the last forty years. After the waterfall processes and structured methods reigned supreme in the 1970's and 1980's, formal use-case and object-oriented analysis and design approaches dominated the 1990's. Then, at the turn of the century, Kent Beck's eXtreme Programming was the first of a wave of more informal, self-styled agile approaches to become widely popular.
Scrum, FDD, Lean, and Kanban
In the last few years, eXtreme Programming's popularity has declined steadily and Ken Schwaber and Jeff Sutherland's Scrum has become the de facto starting point for teams wanting to adopt a more agile approach to software development. Jeff De Luca's Feature-Driven Development (FDD) is cited in some studies as the third most used agile approach despite far less publicity surrounding it. In practice, most teams starting with Scrum, inevitably end up incorporating ideas and practices from both eXtreme Programming and FDD, and frequently from the Poppendiecks' Lean Software Development and David Anderson's Kanban too.
Great Teams Trump Process
However, despite all this innovation, hard work, and debate around different software development processes, methods, and approaches, none of them has been able to replace the importance of building a great team of good people. No process, method, or approach, agile or otherwise, can make up for a fundamental lack of ability, experience, or character within a team.
What makes good tooling for
modern, software development teams?
Most agree it includes tools for performing automated builds
and
testing, includes version control of source code and related resources,
and a modern integrated development environment(IDE) for individual
developers such as Eclipse, Visual Studio, or Xcode.
Cross-functional Team Tools
However, when it comes to project management, requirements
management, and design, general consensus is much harder to find. Most tools in this
space present atrocious user
interfaces, and many suffer from serious feature-bloat. In addition, most are point
solutions that do
not reflect the cross-functional nature of many modern software
development teams.
Tools and Teams
Good software development teams excel at selecting the right tool
for the right job at the right time. And sometimes the right tools are
sticky notes, index cards, flip chart paper, or white boards. Other
times the right tool is a traditional, single-user, PC application,
or a collaborative, web-based product.
Unfortunately, the converse is true, and good tools can rapidly turn into bad tools in the hands of unskilled, inexperienced, or immature teams and organizations. Sometimes it is a poorly evaluated mandate from senior management to use a particular tool. Other times, it is a lack of training or misunderstanding of the tool's purpose, or simply trying to use the tool at the wrong time.
Also, an under-resourced centralised administration team can seriously hamper the effectiveness of tooling by locking down user options to reduce their workload, instead of empowering teams to better administer the tool themselves.
Jeff De Luca, Nebulon
"Deliver frequent, tangible, working results"
Peter Coad
I'm Stephen R. Palmer, a software development consultant at hybris, and www.step-10.com is my personal web site. By the way, I am not trying to be pretentious; the middle initial is simply to distinguish me from all the other different Stephen Palmers. There are many of us out there doing all sorts of interesting things but most of it is not me!
The majority of stuff on this site relates to my two main
professional interests, that of analysis
and design of complex enterprise software systems and related software development methods -
in particular Peter
Coad's 'modeling
in color' technique and Jeff De
Luca's Feature-Driven
Development (FDD) process. Other topics covered include software development tools I love
and loathe, the pragmatic use of UML, and, for something
completely different, places I have
lived in, worked at, or lived near.
My professional experience ranges from near real-time electricity power station,
transmission cables and sub-station monitoring systems to
enterprise-wide agile transformation and service-oriented architecture
projects; from complex commercial
lending systems in Singapore
to global commercial insurance systems in Rhode Island, and from UML
training in the UK to agile coaching in the Netherlands.
As this is my personal website and developed more as a hobby than anything else, the views expressed here are my own and do not necessarily coincide with those of my current or previous employers. I'll also apologise in advance for the occasional misspelling, poor use of grammar, and broken link - it's all 'fixed in the next release' :-)
WARNING: Site under heavy reconstruction at the moment!