I have worked with so many architects in my career, including those who have the “Architect” word in their business card and those who play architect role in their projects. And while I had good fortune to meet very talented people, I am frequently disappointed by poor architects who put their ego, arrogance, fanaticism (and sometimes, ignorance) before anything else. Recalling the memories I have about the poor architects, I come up with the following grouping. Read more…
I’ve come across the latest paper from Ivar Jacobson (yes, one of the “Three Amigos” who invented the RUP and UML) about development processes (Enough of Processes: Let’s Do Practices Part I and Part II) and so much as I admire Mr. Jacobson and his contribution to the software industry, I just do not find anything he wrote in this latest essay new or provoking, especially to those who have been working with agile processes like XP, or Scrum. Read more…
Below is an adaptation of an email I wrote to my team when we started developing a new project in a domain we had not worked with before. One of the key points of the email was that not only business analysts, but developers also needed to possess a fair amount of domain knowledge, besides their technical skills. What are your take on the need of having developers mastering domain knowledge? Do you think it is critical for the success of a project?
Read more…
In 1975, Frederick P. Brooks wrote one of the most influential books in the software engineering field, The Mythical Man-month. Within this book, the essay with the same name, The Mythical Man-month, is cited the most by many software managers, but unfortunately, it is much less often read or understood. Read more…
Hai raised a question about the need for QCs in a project team. Basically he described an situation in which a manager was probed by a developer who believed QCs were not necessary for the project team because developers and BAs could handle all the QC’s tasks, and thus, having the QCs was an unnecessary effort. Read more…
1. The Code is the Design
At university, most of us are taught that the development of a software should go through the following phases: requirement specification, design, construction (or coding), and testing. By gathering system requirements (e.g. from the clients, market researches etc.), analysts would come up with a bunch of functional and supplementary requirement documents, use case model and specifications during the requirement specification phase. Read more…
In my opinion, YAGNI is one of the most misleading practices of eXtreme Programming because it can easily be used as an excuse by some designers to create simplistic and rigid design. Read more…
Lidor Wyssocky wrote a post about the way process should be grown out of project needs and he calls that Flexible Software Development (or FlexDev). He basically argues that people should not be bought into any kind of development processes (e.g. RUP, XP, Scrum) or practices (e.g. TDD, pair programming), instead they should just work out a process of their own during the development life-cycle, depending on the project needs. This can be summarized by the following statement of Lidor Read more…
Fed up with the agile hypes and want to hear from both sides of agile development? Have a look at Steve Yegge’s rants. You can also follow up with an excellent post by Jonathan Kohl about agile which I totally agree about. The best process has no name, no “must have” or “must remove” practices, is documented carefully in no book, consists of whatever works and makes sense in the specific context of the project. Methodologists and researchers may and should describe or propose principles and practices but not the processes themselves, which must be the work of the development teams.
Recent Comments