JoseB Blog

An IT Project Methodology describes how project work is identified, documented, assigned, tracked, tested, and deployed to end users.  At the start of my career, there was no true use of methodology. Requirements and tracking work was done in an ad hoc manner. A waterfall approach was used where all requirements, design, coding, testing, and deployment were done in their entirety one after the other.  This did not work well because by the time we got around to testing and the end users saw the app for the first time, often they would say, 'Hey this is not bad but really, it's not what we wanted, we wanted it like this instead, bla bla bla.' But by then the app was coded 100%, so it was too late to go back and do a rewrite because it would be too much work.  In the end, we would patch the app with band aids to give end users something resembling what they really wanted.  Later in my career, I was exposed to several methodologies including Method1, RUP, and eXtreme/Agi...

Here are the seven disciplines that you must get right, or the project will fail. This means if you get just one of these wrong but the rest right, the project will still fail. It's all or nothing. It's very unforgiving. It's like a chain, if one link fails, the whole chain fails. Methodology - how the project work is managed Requirements - what the app will do Architecture and Design - the foundational structure of the app User Interface - what end users see and interact with Coding - self explanatory Testing - self explanatory Environments and Deployment - how the app moves from development to production We will dive deeper into all of these in later articles, but for now the question becomes, "How do we guarantee that we succeed in each discipline?" The answer is that there must be one person on the team that is responsible and accountable for making sure that quality is maintained in each discipline.   We will get into the different roles of the project team m...

I graduated from college in 1978 as a Computer Science major and worked in IT for forty-one years, retiring in 2019. In my career I programmed apps on everything from standalone mainframes to internet connected phones. In 2001, I was somewhat reluctantly promoted to IT Management at a large company employing hundreds in the IT Department and that is where all my technical project management experience comes from. There, I was exposed to many different IT methodologies, and thru trial and error, I arrived at a development approach that worked well. It borrowed mostly from agile / extreme methodologies, but also borrowed some of the useful RUP artifacts such as the Use Case and the UML Class and Sequence diagrams.  I managed a team of custom app developers, and it took years of hard knocks to learn what worked and what didn't, but in the end the driving force was always to BE PRACTICAL and only do those things that provided value in terms of making the project succeed, so agilit...

There are super stars in every field. After all, you have world class lawyers, doctors, architects, engineers, etc... The same goes for developers. Everyone should be given an equal opportunity to succeed,  but not everyone is equally talented or productive. For this reason managers need to treat their team members differently and even unequally in certain cases. I realize saying this may be controversial, especially to an HR person, so I will clarify.   Early in my career I had a manager who considered himself very fair and he treated everyone the same.  He was a stickler for details regarding punctuality, appearance and rules and regulations and gave anyone (whether junior or senior) a hard time if these rules were not followed to a tee. Eventually this manager lost all his experienced senior developers. Why? Its because they expected better treatment and perks given their superior work quality and productivity. The lesson here is that you give your best peopl...

I believe that the vast majority of the best IT Managers out there were former developers.  In my 41 years in IT, I have worked for a variety of managers and without question the ones who had a technical background were the best. If you think about it, it makes sense. Here are some reasons why: IT Managers are often called upon to troubleshoot failing IT Projects. Projects can fail for different reasons but the root cause is always founded in one of the following.  How can someone with no developer experience know how to figure out where a project is failing? Poor project planning (task estimation, sprint planning) Incomplete requirements Flawed architecture or design Poor quality code Poor testing Poor or no deployment process Non technical managers often focus on metrics to measure project progress and quality (like lines of code, use cases done, bug counts). Unfortunately developers know how to rig metrics 99 times out of 100 in their favor to hide the reality of what'...

What is LDAP? The P in LDAP stands for Protocol, the same as the P in HTTP and FTP. So right off the bat you see that LDAP is a protocol that is at the application level (same as FTP and HTTP) that rides on top of TCP/IP (a transport level protocol). Like HTTP and FTP, LDAP is based on a client sever model. You have an LDAP client that connects to an LDAP server and sends LDAP requests and receives LDAP responses. LDAP services typicallly run on port 389. Unlike HTTP which is a stateless protocol (no connection is kept alive between requests by a client), LDAP is more like FTP in that you have to connect with credentials (called binding), perform operations (typically to lookup data in the directory) and then disconnect (aka unbinding). An interesting thing is that LDAP is supported by browsers (just like FTP is also supported by browsers) and you can enter an address like ldap://UrlAddress/ and the browser will switch to the LDAP protocol and pop up a small window to let you do dire...