The List

Martin Fowler

Martin Fowler is the author of several notable CS books; his most notable book is Patterns of Enterprise Application Architecture (currently reading this at the moment). The articles on his blog are interesting and thought provoking.

• Martin’s blog [ RSS ]

ThoughtBlogs

ThoughtBlogs is the aggregation of articles from tons of ThoughtWorks‘ employees (consulting company). It’s worth looking at because they hire some pretty smart people; Martin Fowler is their chief scientist.

• ThoughtBlogs [ RSS ]

Tim Berners-Lee
For those of you who don’t know, Tim Berners-Lee was the first person to successfully establish an connection between an HTTP client and server (he invented the intarwebz), and now serves as director of the W3C.

** Be advised; this doesn’t get updated very often.

• Tim’s blog @ DIG [ RSS ]

Ivar Jacobson

Ivar was one of the 3 developers (along with Grady Booch and James Rumbaugh) who developed and defined UML and the Rational Unified Process. He maintains a blog that has some interesting articles.

• Ivar’s blog [ RSS ]

Grady Booch

Grady Booch was one of the other “3 Amigos” (listed above) to develop UML and the RUP. He now works at IBM Research as chief scientist of the Software Engineering group.

**At the time of writing this post, his website seems to be down. Google’s cache shows that the last cached version was on Nov. 20, 2008. Hopefully he gets it fixed soon!

• Booch’s blog [ RSS ]

Mark Russinovich

Mark is a technical fellow at Microsoft in the research group; he was co-creator of Sysinternals when it was usurped into MS. He updates at a decent rate and his articles are pretty long.

• Mark’s blog [ RSS ]

Raymond Chen

Raymond is a well known developer for Microsoft’s Windows Shell team. The writing style for his blog and book, both titled The Old New Thing, is very witty and funny; it’s a pretty good read.

• Raymond’s blog [ RSS ]

Jakob Nielson

Jakob is a leading web usability consultant; he writes usability articles for his website, useit.com. The site contains some really interesting articles on usability and human-computer interaction. For example, read his article on the “F-Shaped Pattern For Reading Web Content“.

His site isn’t pretty, and it doesn’t really follow his own guidelines; nevertheless, the articles are worth reading. Unfortunately, Jakob missed the boat on RSS feeds, so you can only subscribe via his mailing list.

• Useit.com’s Alertbox

Seth Godin

This is not really a CS blog at all; however, I did include this for SEO and internet marketing. Many consider Seth Godin to be a genius at marketing. You can see some of his talks online that he’s done at various businesses and events: @ Google, @ Gel 2006, @ TED, @ 2008 Inbound Marketing Summit, and a presentation on his book, Tribes.

• Seth’s blog [ RSS ]

Google Blog’s

Google has a whole slew of blogs for their products and some other topics they like to cover. Some of them are good, and some of them are just product update articles; therefore, I listed the ones that I thought contained the most interesting articles.

• Google Research Blog [ RSS ]
• Google Testing Blog [ RSS ]

Google Employees

• Mark Chu-Carroll’s blog [ RSS ] via Christopher Roach
• Steve Yegge’s blog [ RSS ]

IBM’s developerWorks Sites

The IBM developerWorks sites contain some pretty useful information about the respective topics they cover. The IBM employees in those groups write the articles for the sites and many of the articles are worth reading.

• Architecture [ RSS ]
• Web services [ RSS ]
• Web development [ RSS ]
• Java [ RSS ]
• Linux [ RSS ]

You can find IBM employee blogs and the rest of IBM’s feeds

• developerWorks’ other RSS feeds

Something Missing? Sucked? Good?

Do you think something’s missing from this list? Let me know, so I can update it.

Did this list suck? Let me know (in the constructive way) how to fix it.

Was this list Good? Rate the article and leave a comment?

Rapid prototyping can be a wonderful thing for involving the end customer in the design and development process; it can make them happy (it shows progress) which makes you money; however, if you have the wrong kind of customer, your life as a developer can becoming a living nightmare. The horror is increased by several orders of magnitude if you have the requirement to produce fully functional prototypes.

What Is Rapid Prototyping?

It’s a software development process that involves creating incomplete prototypes of an application that either helps build or build toward the ideal of the final design of the application.

There are several different methods of rapid prototyping as listed on the Wikipedia article:

• Throwaway – none of the actual code developed will be used in the final product (FAST)
• Evolutionary – iterative design and development of functional prototypes (and the code used isn’t thrown away)
• Incremental – piecemeal construction of a larger prototype using smaller prototypes
• Extreme – like everything else but has a period where mock-data is used

Advantages of Rapid Prototyping (via Wikipedia article)

• Lowered development time and costs
  • Less process to get in the way of defining; the customer can see requested changes fast
• Increased customer involvement in design and development
  • User’s can give immediate and incremental feedback on the prototypes so they end up with a much happier, better functioning product

Why Is It So Bad Then?

If you have a customer that would like something, but they don’t know what they want, and they tend to get stuck on telling you how to implement their something instead of real concrete requirements. RUN!!!

Let’s just take a quick look at the disadvantages…

Disadvantages of Rapid Prototyping (via Wikipedia article)

• Poor/insufficient analysis
  • Since you were busy coding your life away on a feature that’s not really “production-ready” and you only have a week or two to finish, you might not have had enough time to sit back and really think about your design. You could make some dumb mistakes that could have been fixed by thinking about the problem from a different angle or using more time.Now imagine every other developer working on the same project but on different parts! You may have a functional prototype, but it may well easily be a big ball of hack
• Customers don’t tend realize that the prototype is a “prototype“
  • This one can be really bad. If you give a customer a prototype release with the GUI features working but the data is not really connected to the real data (so that you could ask them if this new GUI feature was what they wanted), they will always try to use it as a final product and ask instead, “where’s my data?“
  • Rapid prototyping tends to allow the customer to foucs more on the minute volatile details rather than the larger picture or the workflows.
  • Another problem, once the customer sees a feature, they tend to stick with that feature even though it may evolve. They have been trying to imagine the solution to their problem, and you give them a half-arse solution; the next release you give them something better or it changes and they will want to stick with the old and poorer features (i.e. once you’ve laid the track around the mountain, they won’t like it if you decide to tunnel the track through the mountain even though it might have been shorter/cheaper/better/whatever)
• Clouding of the developer’s goals and mission as compared to the customer
  • The customers will ask for features sometimes, and everyone thought they knew what the customer meant by those features/requirements; however, what they wanted and what was interpreted can become skewed and misaligned. To help you out, make sure to ask them for the business case for everything they are requiring! Ask, ask ask! They need to know why they are asking for the new feature.
• Developers are too attached to their creations
  • Developers might spend 40+ engineer hours each on a feature, and when the prototype iteration is released, the customer might say to throw the feature out. Developers will try to persuade the customer that it’s a viable feature (even though it may not); developers really don’t like wasting their coding time; however, it is a prototype so developers should be ready for features (especially those with a lot of sweat and blood in them) to be thrown out or never used.
• Way too much development time of a prototype
  • This is where the paradox of rapid prototyping exists because RP boats faster time to market. Developers tend to over-architect and spend way too much time on the features of a prototype for efficiency or whatever reason, and a change in the requirements or features totally negates the time spent on the architecture. When it comes down to it, development teams really need to make their deadlines, so don’t over-architect a feature that the customer isn’t completely gang-ho for; just put enough design in to mitigate medium-level risks until the feature is solidified.
  • There also exists a big balance issue here: do you sacrifice design for lowered development time? or do you extend the development time for better analysis and design? It’s all dependent on what type of prototyping you want to do; throwaway-prototyping makes it much easier to hack away and come back later for better analysis and design

What does it all mean?

It means that developers tend to work a ton of time (just to make the release deadlines) on over-architected features that the customer may or may not want.

How satisfactory is it for a developer when the stuff they create is destroyed?

Case Study: IT Asset Adhoc Reporting

Background:

Our customer has a contract with another very large company to audit the IT assets that the customer has. The original requirements for that large company were to produce quite a few reports of the IT asset audit status.

The customer then asked this contractor to produce a queryable form for all the IT assets, so the large contractor gave them a MS Access database with very elementary MS Access query Form.

We had the job to migrate the MS Access database into Oracle for reporting purposes, which stunk because there were no primary-key or foreign-key constraints enforced (replicated data was in the Access DB)

Adhoc Reports (ranting…)

The customer wanted us to create a mechanism for adhoc query reporting, but they didn’t know what they wanted, so we researched for a week on the industry standards of adhoc query reporting like JReport or some other type of business intelligence suites that had lots of features like pivot tables, drag-and-drop report generation, and drill-down capabilities.

We presented the idea to them and they said that they just wanted something that functioned like the MS Access query form, so we did that. Then they complained that the form looked like the MS Access query form!!!

We then needed to glean the report generation workflow from them and gave them working prototypes of each workflow. Their comments back were, “the form is missing these fields“, “the font is too big“, and “I want a green popup when I hover over this thing” instead of “we like workflow option 2″ or whatever.

We have been asking questions constantly about the requirements and the answers come back in the form of more questions!!! It’s just the way this customer is. Moreover, since we constantly ask them questions about the prototypes for feedback, they decided to take that as an offense and they complained to their higher ups that we weren’t doing anything. So what did we do? Make prototypes in closer release intervals! BAH!

Moreover, they told use that we can’t warehouse the data to normalize it, but yet they complain that they see null’s and replicated fields.

Since we aren’t a bunch of dumb developers, we like making good quality products, and when the requirements change as much as they do, it’s sad to see your stuff that you created just go to waste. I can’t tell you how many lines of code were just thrown away. I know that some of the readers will be saying, “well, you should have designed it better”. Well yeah, we know!!! However, with two week release cycles it’s pretty hard to do that when the requirements end up changing the design dramatically; moreover, I don’t want to work 80 hours a week on design that might change anyway.

However, they do pay the bills, so we must do as we are told. Enough of my complaining. This wasn’t as much of a case study as it was a rant I guess, and I do apologize.

The point of this is that it takes a lot of sweat and blood to make these prototypes, and the customer is just never happy; therefore, we aren’t happy.

Moral of the Story: If you are going to chose a prototyping method, use throwaway!!! It will be the best for everyone, and you won’t deliver a ball of hack as your final product.

Has Anyone Else Experienced As Much Trouble with Rapid Prototyping?

What are Your Comments on RP?

Please leave a comment on your expieriences and thoughts of rapid prototyping!!

We were starting to get sick of the “X# Design Websites That Web Designers Need To Follow!!11!!” articles and other similar items pertaining to web development design coming through the pike on the social news sites like Digg and Delicious (we won’t even bring up reddit… try reducing the stories to programming), so we decided to do something about it.  There is nothing wrong with those articles, but every once in a while it would be good to see a resource that talks about enterprise design; unfortunately, not everyone is a freelance web-developer.

So we decided to put together a list of books that we thought you should read to make you a better software engineer…

1. Patterns of Enterprise Application Architecture

Author(s): Martin Fowler

Publisher: Addison-Wesley Professional

ISBN: 978-0321200686

Linky: Amazon

This book serves as a good base for enterprise application architecture and comes highly recommended.  The book is written in 2 parts: the first part of the book serves as a tutorial and foundation for developing enterprise applications (things like MVC, business logic organization, concurrency, object registries, Object Relational topics, etc), the second part is a pattern catalog.  A list of the patterns and short descriptions/UML can be found on the author’s website.

For those of you unfamiliar with Martin Fowler, you need to be.  He is a brilliant speaker, writer and software architect that works for the ThoughtWorks consulting firm.  His website has a plethora of information and articles that are worthwhile reading; moreover, his blog (er um “bliki”) has some very thought-provoking articles.

2. Core J2EE Patterns

Author(s): Deepak Alur, Dan Malks, John Crupi

Publisher: Prentice-Hall (2nd Edition)

ISBN: 978-0131422469

Linky: Amazon

This book serves as the goto-book for the patterns used in the J2EE spec; it covers the different components in the J2EE Model-View-Controller architecture such as front-controller, data-access-object (DAO), view-helpers, application-service, session-facade, etc…

The book divides the patterns into the three application tiers: presentation tier, business tier, and integration tier.  This serves as a much better source for the patterns than trying to dig through Sun’s J2EE tutorial. If you don’t buy the book, at least make pattern cards for those patterns!

The book’s website (http://www.corej2eepatterns.com) also lists and describes the design patterns in the book; there is also a giant class interaction diagram.

3. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Author(s): Gregor Hohpe, Bobby Woolf

Publisher: Addison-Wesley Professional

ISBN: 978-0321200686

Linky: Amazon

This was another wonderful book for those that are interested in learning about enterprise messaging. The obvious choice for this is using Java’s JMS system (or the JMS extended counterparts: Websphere MQ (MQSeries), JbossMQ, MSMQ, etc); however, the book does talk about other systems of messaging: file-based, RPC, shared DB, etc.

Messaging is great for enterprise applications because it offers an easy solution (not necessarily by code or setup) to any problem that needs both/either synchronous and/or asynchronous communication. The book talks about many topics dealing with messaging: systems, channels, construction, routing, control, endpoints, transaction, delivery and other topics.

Some of the example patterns covered include: wire-tap, aggregator, event-driven-consumer, smart-proxy. You can see the full pattern catalog at the book’s site.

4. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Author(s): Craig Larman

Publisher: Prentice-Hall (3rd Edition)

ISBN: 978-0131489066

Linky: Amazon

Some people would scoff at us for including this book in the list; well, we did anyways because it is worth it.  If you are a beginner to mid-level software engineer/developer and you don’t know what any of these terms are: agile, Unified Process, UML, OOA&D, GRASP, and GoF… then this is the book for you.

Larman does a pretty good job of describing an agile software development process and some of the basic documentation needed for designing a robust application/system (patterns, requirements gathering, iterations, planning, diagramming, use-cases).   He uses UML (Unified Modeling Language) and the Unified Process to walk you through the foundational concepts of object-oreinted analysis and design, and he includes a fake case-study as an example.

He also mentions and describes the use of the design patterns developed by the GoF (Gang of Four = Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and what are known as the GRASP patterns: General Responsibility Assignment Principles (Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations).  The GRASP patterns (developed by Larman) describe ways and best-practices for assigning responsibilities to an object during design.  The book goes into detail but you can read the highlights on Wikipedia.

5. Introduction to Algorithms

Author(s): Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein

Publisher: MIT Press (2nd Edition)

ISBN: 978-0262032933

Linky: Amazon

If you were ever looking for an algorithm dictionary, this would definitely be it. Don’t let the word “Introduction” in the title scare you away from this book; it’s the exact opposite.

To rattle off just a few of the topics and algorithms covered: master method, randomization, heapsort, quicksort, asymptotic runtime analysis, medians and order statistics, stacks, queues, linked lists, hash tables, perfect hashing, binary search trees red-black trees, dynamic programming, huffman codes, greedy algorithms, minimum spanning tree, optimal subset, amortized analysis, b-trees, splay trees, binomial heaps, fibonacci heaps, disjoint sets, strongly connected components, rank and path compression, graphs, all pairs shortest paths, breadth first search, depth first search, topological sort, minimum spanning trees, kruskal’s algorithm, prim’s algorithm, dijkstra’s algorithm, ford-fulkerson method, maximum flow min cut, edmonds-karp algorithm, comparison networks, bitonic sorting network, matricies, strassen’s algorithm, solving systems of linear equations, linear programming, polynomials, discrete and fast fourier transform, RSA public-key cryptosystem, primality testing, string matching, rabin-karp algorithm, knuth-morris-pratt string matching, computational gemotry, line and segment intersection, vertex cover, convex hull, np-complete problems, traveling salesman.

The pseudo-code is a little annoying if you are used to counting from 0…n-1 because they start from counting from “1″ instead.

As a side note, I’d like to see them write the non-introductory version of this 1184 page book!

6. Design Patterns: Elements of Reusable Object-Oriented Software

Author(s): Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Publisher: Addison-Wesley Processional

Linky: Amazon

Whenever you hear the words “software” and “pattern” used in a sentence together, you’ll likely hear this book title or the synonym for the group of authors thrown in somewhere in the mix because this is the definitive source for software patterns.  Whenever someone mentions GoF or Gang-of-Four or buying their book, this is what they are talking about (referring to the “gang” of the four authors of this book)

The book is divided into two parts. The first part talks about object-oriented programming in general and includes a case study on a WYSIWYG editor using pseudo-code and UML diagrams; the second part is the detailed description of the following 23 patterns…

Creational Patterns

• Abstract Factory, Builder, Factory Method, Prototype, Singleton

Structural Patterns

• Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Behavioral Patterns

• Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

This book is a must-get just for the collection of patterns alone.

7-15. Any Other Book from the Addison-Wesley Signature Series

Author(s): many…

Publisher: Addison-Wesley Professional

Linky: Amazon

Honestly, all of these books can add be added to your list of things to read they are all completely amazing in the fields that they cover. Martin Fowler and Kent Beck signed off on the books that were put in this series. Some of the books that are listed…

User Stories Applied	Test Driven Development
Implementing Lean Software Development	xUnit Test Patterns
Continuous Integration	Implementation Patterns
Refactoring Databases	Beyond Software Architecture
Refactoring To Patterns	Refactoring HTML
Growing Object-Oriented Software, Guided by Tests	Aspect Oriented Refactoring

Give Me More!!!

Go have a ball with Wikipedia’s List of Important Publications In Computer Science

Update: Code Style

So I have noticed that my article mentions software engineer; I am sorry for my selection of diction. Maybe I should have said software developer as to not piss people off.

However, since we are on the topic… I thought that I might add a few more books having to do with code style to help you out!

The Elements of Java Style

Author(s): Allan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, Alan Vermeulen, Patrick Thompson

Publisher: Cambridge University Press

ISBN: 978-0521777681

Linky: Amazon

This is a very short book that serves as Java style conventions in several areas: formatting, naming conventions (variable, class, package, method, etc), programming conventions (type safety, construction, execption handling, synchronization, etc), and documentation conventions. If you are looking for a common convention for you or your group to follow. This is a start.

It’s also worth it to check out the rest of the SIGS Reference Library.

There are two more books that follow the same flow that I would like to recommend:

Now I know that someone is going to say… UML ISN’T CODING! They would be correct, but I felt that since you should be able to generate code from UML and UML from code, I figured that I would throw it on there as well; moreover and more importantly, it will force you to find a style!!!