During 2011-2012 there was a small but significant revolution in how we worked at Thoughtworks. When we needed to communicate while separated we used to do telephone meetings, but within a year the telephone disappeared and we started using video calls instead. As we got more comfortable with video, we took more opportunity to collaborate with video meetings rather than trying to get everyone toge
A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality. Betteridge's Law of headlines is an adage that says
Should I use a Rules Engine? A rules engine is all about providing an alternative computational model. Instead of the usual imperative model, which consists of commands in sequence with conditionals and loops, a rules engine is based on a Production Rule System. This is a set of production rules, each of which has a condition and an action - simplistically you can think of it as a bunch of if-then
In the very earliest days of Object-Orientation, the OO advocates like me put a lot of attention into arguing in favor of reuse. Early on we talked about reusing of classes. Then we discovered that reusing individual classes, while it worked in some cases, didn't work so well elsewhere. So we got into reusable frameworks, which got us part-built applications of functionality. On the technical side
While I was at the QCon conference in London a couple of months ago, it seemed that every talk included some snarky remarks about Object/Relational mapping (ORM) tools. I guess I should read the conference emails sent to speakers more carefully, doubtless there was something in there telling us all to heap scorn upon ORMs at least once every 45 minutes. But as you can tell, I want to push back a b
The term 'command query separation' was coined by Bertrand Meyer in his book "Object Oriented Software Construction" - a book that is one of the most influential OO books during the early days of OO. (The first edition is the one that had the influence, the second edition is good but you'll need several months in a gym before you can lift it.) The fundamental idea is that we should divide an objec
This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find ti
Sequence diagrams illustrate the difference quite well. Figure 1 uses the request collaboration style. When I tell Zen I'm going out it queries the temperature sensor for the temperature, uses this information to figure out what coat I'll need and tells the valet to get the down jacket. There are two elements to the collaboration here: the query Zen issues to the temperature sensor and the command
Service Layer by Randy Stafford Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation. For a full description see P of EAA page 133 Enterprise applications typically require different kinds of interfaces to the data they store and the logic they implement: data loaders, user interfaces,
Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior using SpecificationByExample. It's an approach developed by Daniel Terhorst-North and Chris Matts as part of Behavior-Driven Development (BDD). [1] It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the Four-
2 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE W andering down our corridor a while ago, I saw my colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement, “We shouldn’t interview anyone who has ‘architect’ on his resume.” At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our le
Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's. People commonly ask questions about use cases, most of which can be answered by Alistair Cockburn's book, which is by far the best book on use cases. You should read this book before using or asking questions about use cases. Use cases appear in th
[突撃インタビュー] Martin Fowler氏のセミナーの直後、ホテルのティールームで、お忙しいなか快くインタビューに応じてくださいました。 メンバーは、Martin Fowler氏とオージス総研の突撃隊員3名、それからエヌケーエクサの児玉さんも同席です。常時和やかなムードで進んだインタビューの様子をお伝えします。 茶色の文字が突撃隊員の質問です。 左より、隊員1(梅澤)、隊員2(羽生田)、Martin Fowler氏、隊員3(越智)、児玉氏 まずは一般的な話題から 日本に来られたのは初めてと伺いましたが、着いたのはいつですか? 月曜日だよ。 (インタビュー当日は水曜日。Fowler氏は火曜日・水曜日のセミナーに出席されていました。) どこかに行かれましたか? ホテルで寝ただけ。 では、日本の印象はまだ... インターナショナルなホテルは、どこでも同じだからね。明日、京都と奈良に行くか
Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on t
We see so much emotional discussion about software process, design practices and the like. Many of these arguments are impossible to resolve because the software industry lacks the ability to measure some of the basic elements of the effectiveness of software development. In particular we have no way of reasonably measuring productivity. Productivity, of course, is something you determine by looki
Laura Paterson, our office Principal in London, caught up with Martin Fowler last week about his upcoming book, a new edition of the classic text book ‘Refactoring’. From the great functional debate to advice for career changers, we’ve captured the whole thing for you in two short Q&As. The second part of the discussion is coming soon — sign up for Access TW here (unless you're already a member) t
There's a mess I've heard about with quite a few projects recently. It works out like this: They want to use an agile process, and pick Scrum They adopt the Scrum practices, and maybe even the principles After a while progress is slow because the code base is a mess What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake you'll
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く